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Abstract 
This document describes the requirements and implementation of a 


group telephony feature commonly known as Bridged Line Appearance 
(BLA) or Multiple Line Appearance (MLA), or Shared Call/Line 


Appearance (SCA). When implemented using the Session Initiation 
Protocol (SIP), it is referred to as shared appearances of an Address 
of Record (AOR) since SIP does not have the concept of lines. This 


feature is commonly offered in IP Centrex services and IP Private 
Branch Exchange (IPBX) offerings and is likely to be implemented on 
SIP IP telephones and SIP feature servers used in a business 
environment. This feature allows several user agents (UAs) to share 
a common AOR, learn about calls placed and received by other UAs in 
the group, and pick up or join calls within the group. This document 
discusses use cases, lists requirements, and defines extensions to 
implement this feature. This specification updates RFCs 3261 and 
4235. 
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1. Introduction 


The feature and functionality requirements for SIP user agents (UAs) 
supporting business telephony applications differ greatly from basic 
SIP UAs, both in terms of services and end-user experience. In 
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addition to basic SIP support [RFC3261], many of the services in a 
business environment require the support for SIP extensions such as 
REFER [RFC3515], SUBSCRIBE/NOTIFY [RFC6665], PUBLISH [RFC3903], the 
SIP Replaces [RFC3891], and Join [RFC3911] header fields, etc. Many 
of the popular business services have been documented in the SIP 
Service Examples [RFC5359]. 


This specification details a method for implementing a group 
telephony feature known variously in telephony as Bridged Line 
Appearance (BLA) or Multiple Line Appearances (MLA), one of the more 
popular advanced features expected of SIP IP telephony devices in a 


business environment. Other names for this feature include Shared 
Call/Line Appearance (SCA), Shared Call Status and Multiple Call 
Appearance (MCA). A variant of this feature is known as Single Line 
Extension. 


This document looks at how this feature can be implemented using 
standard SIP [RFC3261] in conjunction with SIP events [RFC6665] and 
publication [RFC3903] (carrying the SIP dialog state event package 
[RFC4235]) for exchanging status among UAs. 


In traditional telephony, the line is physical. A common scenario in 
telephony is for a number of business telephones to share a single or 
a small number of lines. The sharing or appearance of these lines 
between a number of phones is what gives this feature its name. A 
common scenario in SIP is for a number of business telephones to 
share a single or a small number of Address of Record (AOR) URIs. 


In addition, an AOR can have multiple appearances on a single UA in 
terms of the user interface. The appearance number relates to the 
user interface for the telephone; typically, each appearance of an 
AOR has a visual display (lamp that can change color or blink or a 
Screen icon) and a button (used to select the appearance) where each 
appearance number is associated with a different dialog to/from the 
AOR. The telephony concept of line appearance is still relevant to 
SIP due to the user interface considerations. It is important to 
keep the appearance number construct because: 


1. Human users are used to the concept and will expect it in 
replacement systems (e.g., an overhead page announcement says 
"Joe pickup line 3"). 


2. It is a useful structure for user interface representation. 
The purpose of the appearance number is to identify active calls to 
facilitate sharing between users (e.g., passing a call from one user 


to another). If a telephone has enough buttons/lamps, the appearance 
number could be the positional sequence number of the button. If 
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not, it may still be desirable to present the call state, but the 
appearance number should be displayed so that users know which call, 
for example, is on hold on which key. 


In this document, except for the usage scenarios in the next section, 
we will use the term "appearance" rather than "line appearance" since 
SIP does not have the concept of lines. Note that this does not mean 
that a conventional telephony user interface (lamps and buttons) must 
be used: implementations may use another metaphor as long as the 
appearance number is readily apparent to the user. Each AOR has a 
separate appearance numbering space. As a result, a given UA user 
interface may have multiple occurrences of the same appearance 
number, but they will be for different AORs. 


2. Conventions Used in This Document 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in RFC 2119 [RFC2119] 
and indicate requirement levels for compliant mechanisms. 


3. Usage Scenarios 


The following examples are common applications of the shared 
appearances feature and are mentioned here as informative use cases. 
All these example usages Can be supported by the shared appearances 
feature described in this document. The main differences relate to 
the user interface considerations of the device. 


3.1. Executive/Assistant Arrangement 


The appearances on the executive's UA also appear on the assistant's 
UA. The assistant may answer incoming calls to the executive and 
then place the call on hold for the executive to pick up. The 
assistant can always see the state of all calls on the executive's 
UA. 


3.2. Call Group 


Users with similar business needs or tasks can be assigned to 
Specific groups and share an AOR. For example, an IT department 
staff of five might answer a help line that has three appearances on 
each phone in the IT work area. A call answered on one phone can be 
put on hold and picked up on another phone. A shout or an IM to 
another staff member can result in them taking over a call on a 
particular appearance. Another phone can request to be added/joined/ 
bridged to an existing appearance resulting in a conference call. 
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3.3. Single Line Extension 


In this scenario, incoming calls are offered to a group of UAs. When 
one answers, the other UAs are informed. If another UA in the group 
Seizes the line (i.e., goes off-hook), it is immediately bridged or 
joined in with the call. This mimics the way residential telephone 
extensions usually operate. 


3.4. Changing UAs 


A user is on a call on one UA and wishes to change devices and 
continue the call on another UA. They place the call on hold, note 
the appearance number of the call, then walk to another UA. They are 
able to identify the same appearance number on the other UA, pick up 
the call, and continue the conversation. 


4. Requirements and Implementation 


The next section details the requirements and discusses the 
implementation of the shared appearances feature. 


4.1. Requirements 


The basic requirements of the shared appearances feature can be 
summarized as follows: 


REQ-1: Incoming calls to the AOR must be offered to a group of UAs 
and can be answered by any of them. 


REQ-2: Each UA in the group must be able to learn the call status 
of the others in the group for the purpose of rendering this 
information to the user. 


REQ-3: A UA must be able to join (also called bridge or conference 
together) or pick up (take) an active call of another UA in 
the group in a secure way. 


REQ-4: The mechanism should require the minimal amount of 
configuration.  UAs registering against the group AOR should 
be able to participate in the shared appearance group 
without manual configuration of group members. 


REQ-5: The mechanism must scale for large numbers of appearances 
and large numbers of UAs without introducing excessive 


messaging traffic. 


REQ-6: Each call or session (incoming or outgoing) should be 
assigned a common "appearance" number from a managed pool 
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administered for the AOR group. Once the session has 
terminated, the appearance number is released back into the 
pool and can be reused by another incoming or outgoing 
session. 


Each UA in the group must be able to learn the status of all 
appearances of the group. 


There must be mechanisms to resolve appearance contention 
among the UAs in the group.  Contention in this context 
means an appearance number being associated with multiple 
dialogs that are not mixed or otherwise associated. 


The mechanism must allow all UAs receiving an incoming 
Session request to utilize the same appearance number at the 
time of alerting. 


The mechanism must have a way of reconstructing appearance 
state after an outage that does not result in excessive 
traffic and processing. 


The mechanism must have backwards compatibility such that a 
UA that is unaware of the feature can still register against 
the group AOR and make and receive calls. 


The mechanism must not allow UAs outside the group to 
select, seize, or manipulate appearance numbers. 


For privacy reasons, there must be a mechanism so that 
appearance information is not leaked outside the group of 
UAs (e.g., "So who do you have on line 1?"). 


The mechanism must support a way for UAs to request 
exclusivity on a line appearance.  Exclusivity means that 
the UA requesting it desires a private conversation with the 
external party and other UAs must not be allowed to join or 
take the call.  Exclusivity may be requested at the start of 


an incoming or outgoing session or during the session. An 
exclusivity request may be accepted or rejected by the 
entity providing the shared appearance service. Therefore, 


the mechanism must provide a way of communicating the result 
back to the requester UA. 


The mechanism should support a way for a UA to seize a 
particular appearance number for outgoing requests prior to 
sending the actual request. This is often called seizure. 
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REQ-16: The mechanism should support a way for a UA to seize a 
particular appearance number and also send the request at 
the same time. This is needed when an automatic ringdown 
feature (a telephone configured to immediately dial a phone 
number when it goes off-hook) is combined with shared 
appearances. In this case, seizing the line is integrated 
with dialing. 


4.2. Implementation 


This section non-normatively discusses the implementation of the 
shared appearances feature. The normative description is in 
Section 5. Many of the requirements for this service can be met 
using standard SIP mechanisms such as: 


o A SIP Forking Proxy and Registrar/Location Service meets REQ-1. 
o The SIP Dialog Package meets REQ-2. 


o The combination of the SIP Replaces and Join header fields meets 
REQ-3. 


o The use of a State Agent for the Dialog Package meets REQ-4 and 
REQ-5. 


REQ-6 suggests the need for an entity that manages the appearance 
resource. Just as conferencing systems commonly have a single point 
of control, known as a focus, a shared appearance group has a single 
point of control of the appearance shared resource. This is defined 
as an Appearance Agent for a group. While an Appearance Agent can be 
part of a centralized server, it could also be co-resident in a 
member UA that has taken on this functionality for a group. The 
Appearance Agent knows or is able to determine the dialog state of 
all members of the group. 


While the appearance resource could be managed cooperatively by a 
group of UAs without any central control, this is outside the scope 
of this document. It is also possible that the Appearance Agent 
logic could be distributed in all UAs in the group. For example, 
rules that govern assigning appearance numbers for incoming requests 
(e.g., lowest available appearance number) and rules for contention 
handling (e.g., when two UAs request the use of the same appearance 
number, hash dialog identifiers and compare with the lowest hash 
winning) would need to be defined and implemented. 


To best meet REQ-9, the appearance number for an incoming INVITE 
needs to be contained in the INVITE, in addition to being delivered 
in the dialog package NOTIFY. Otherwise, if the NOTIFY is delayed or 
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lost, a UA in the group might receive an incoming INVITE but might 
not know which appearance number to render during alerting. 


This specification defines an extension parameter, which is 
normatively defined in Section 7, for the Alert-Info header field in 
RFC 3261 to carry the appearance number: 


Alert-Info: <urn:alert:service:normal>; appearance=1 


The following list describes the operation of the shared appearances 
feature. 


1. A UA is configured with the AOR of a shared appearance group. It 
registers against the AOR, then attempts a dialog state 
subscription to the AOR. If the subscription fails, loops back 
to itself, or returns an error, it knows there is no State Agent 
and, hence, no Appearance Agent and this feature is not 
implemented. 


2. If the subscription receives a 200 OK, the UA knows there is a 
State Agent and that the feature is implemented. The UA then 
follows the steps in this list. 


3. Information learned about the dialog state of other UAs in the 
group is rendered to the user. 


4. Incoming calls are forked to all UAs in the group, and any may 
answer.  UAs receive the appearance number to use in rendering 
the incoming call in a NOTIFY from the Appearance Agent and in 
the INVITE itself. The UA will also receive a notification if 
the call is answered by another UA in the group so this 
information can be rendered to the user. 


5. For outgoing calls, the operation depends on the implementation. 
If the user seizes a particular appearance number for the call, 
the UA publishes the trying state dialog information with the 
desired appearance number and waits for a 2xx response before 
sending the INVITE. 


6. For outgoing calls, if the user does not seize a particular 
appearance or does not care, the INVITE can be sent immediately, 
and the appearance number learned as the call progresses from a 
notification from the Appearance Agent. 


7. For outgoing calls, if the user does not want an appearance 


number assigned (such as during a consultation call or if a UA is 
fetching 'service media' such as music on hold [RFC7088]), the UA 
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Dis 


also publishes prior to sending the INVITE but does not include 
an appearance number in the publication. 


Established calls within the group may be joined (bridged) or 
taken (picked) by another UA. Information in the dialog package 
notifications can be used to construct Join or Replaces header 
fields. Since the same appearance number is used for these types 
of operations, this information is published prior to sending the 
INVITE Join or INVITE Replaces. 


The Appearance Agent may not have direct access to the complete 
dialog state of some or all of the UAs in the group. If this is 
the case, the Appearance Agent will subscribe to the dialog state 
of individual UAs in the group to obtain this information. In 
any case, the Appearance Agent will send normal notifications 
(via the subscriptions established by the UAs in step 1) every 
time the aggregate dialog state of the AOR changes, including 
when calls are placed, answered, placed on and off hold, and hung 


up. 


Normative Description 


This section normatively describes the shared appearances feature 


extensions. The following definitions are used throughout this 
document: 
Appearance number: An appearance number is a positive integer 


associated with one or more dialogs of an AOR. Appearance numbers 
are managed by an Appearance Agent and displayed and rendered to 
the user by UAs that support this specification. When an 
appearance number is assigned or requested, generally the assigned 
number is the smallest positive integer that is not currently 
assigned as an appearance number to a dialog for this AOR. This 
Specification does not define an upper limit on appearance 
numbers; however, using appearance numbers that are not easily 
represented using common integer representations is likely to 
cause failures. 


Seizing: An appearance can be reserved prior to a call being placed 


by seizing the appearance. An appearance can be seized by 
communicating an artificial state of "trying" prior to actually 
initiating a dialog (i.e., sending the INVITE), in order to appear 
as if it were already initiating a dialog. 


Selecting (or Not-Seizing): An appearance is merely selected (i.e., 


not seized) if there is no such communication of artificial state 
of "trying" prior to initiating a dialog: i.e., the state is 
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communicated when the dialog is actually initiated. The 
appearance number is learned after the INVITE is sent. 


5.1. Elements 
A complete system to implement this feature consists of: 


1. UAs that support publications, subscriptions, and notifications 
for the SIP dialog event package and the shared appearance dialog 
package extensions and behavior. 


2. An Appearance Agent consisting of a State Agent for the dialog 
event package that implements an Event State Compositor (ESC) and 
the shared appearance dialog package extensions and behavior. 

The Appearance Agent also has logic for assigning and releasing 
appearance numbers and resolving appearance number contention. 


3. A forking proxy server that can communicate with the State Agent. 
4. A registrar that supports the registration event package. 


The behavior of these elements is described normatively in the 
following sections after the definitions of the dialog package 
extensions. 


5.2. Shared Appearance Dialog Package Extensions 


This specification defines four new elements as extensions to the SIP 
Dialog Event package [RFC4235]. The schema is defined in Section 6. 
The elements are «appearance», «exclusive», <joined-dialog>, and 
«replaced-dialog», which are sub-elements of the «dialog» element. 


5.2.1. The «appearance» Element 


The «appearance» element, a child of the «dialog» element, is used to 
convey the appearance number of the dialog described by the parent 
«dialog» element. When sent by a UA in a PUBLISH with parent 
«dialog» with state attribute "trying" to the Appearance Agent, the 
UA is requesting assignment of the given appearance number to the 
current or future dialog with the given dialog identifiers. When an 
«appearance» element is sent by the Appearance Agent in a NOTIFY, it 
indicates that the appearance number has been assigned to the 
Specified dialog. 


Note that a «dialog-info» element describes the contained dialogs 
from the point of view of the UA (named by the "entity" attribute), 
regardless of whether the containing request is sent by the UA or the 
Appearance Agent. In particular, if the UA sent a request within the 
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described dialog, the To header field URI would match the «remote» 
«identity» value and the to-tag parameter would match the remote-tag 
attribute. Similarly, the From header field URI would match the 
«local» «identity» value and the from-tag parameter would match the 
local-tag attribute. 


5.2.2. The «exclusive» Element 


The «exclusive» element, a child of the «dialog» element, is a 
boolean, which, when true, indicates that the UA is not willing to 
accept an INVITE with a Join or Replaces header field targeted to the 
dialog described by the «dialog» element that is the parent of the 
«exclusive» element. For example, some shared appearance systems 
only allow call pickup when the call is on hold. In this case, the 
<exclusive> element should be set to "false" when the call is held 
and "true" when the call is not held, rather than having the 
"exclusive" value implied by the hold state. 


It is important to note that this element is a hint. In order to 
prevent another UA from taking or joining a call, a UA can, in 
addition to setting the <exclusive> tag, not report full dialog 
information to the Appearance Agent. Not having the full dialog 
information (Call-ID, remote-tag, and local-tag) prevents another UA 
from constructing a Join or Replaces header field. Although a UA may 
set <exclusive> to "true", the UA must still be ready to reject an 
INVITE Join relating to this dialog. If these dialog identifiers 
have already been shared with the Appearance Agent, the UA could send 
an INVITE Replaces to change them and then not report the new ones to 
the Appearance Agent. 


If the proxy knows which dialogs are marked exclusive, the proxy MAY 
enforce this exclusivity by rejecting INVITE Join and INVITE Replaces 
requests containing those dialog identifiers with a 403 (Forbidden) 
response. 


Note that exclusivity has nothing to do with appearance number 
selection or seizing -- instead, it is about call control 
operations that can be performed on a dialog. 


If the «exclusive» element is not present, it is assumed to be false. 
5.2.3. The <joined-dialog> Element 

The <joined-dialog> element, a child of the <dialog> element, is used 

to convey dialog identifiers of any other dialogs that are joined 

(mixed or bridged) with the dialog. Only the UA that is the common 


endpoint of the mixed dialogs (and thus controlling the mixing 
operation) should include this element in publications to the 
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Appearance Agent. Note that this element should still be used even 


when the Join header field was not used to join the dialogs. For 
example, two separate dialogs on a UA could be joined without any SIP 
call control operations. Joined dialogs will share the same 


appearance number. 


If the <joined-dialog> element is not present, it is assumed that the 
dialog is not joined or to be joined to any other dialog. 


5.2.4. The <replaced-dialog> Element 


The «replaced-dialog» element, a child of the «dialog» element, is 
used to convey dialog identifiers of any other dialogs that will be 
or have been replaced with this dialog. For example, a UA in the 
group picking up a call on another UA by sending an INVITE with 
Replaces would include this element for the replacing dialog. 
Replaced dialogs will share the same appearance number. 


If the «replaced-dialog» element is not present, it is assumed that 
the dialog has not replaced or is not to replace to any other dialog. 


5.3. Shared Appearance User Agents 
UAs that support the shared appearances feature use the dialog state 


package [RFC4235] with the shared appearance extensions and the 
'shared' Event header field parameter defined in Section 13. 


UAs use the dialog package extensions in Section 5.2 along with 
SUBSCRIBE [RFC6665], NOTIFY [RFC6665], and PUBLISH [RFC3903]. 
SUBSCRIBE, NOTIFY, and PUBLISH requests for the dialog event package 
include the 'shared' Event header field parameter as required by this 
Specification. 


The presence of the 'shared' Event header field parameter tells 
the Appearance Agent that the UA supports this specification. 


Upon initialization, the UA MUST subscribe to the dialog event 
package of the AOR and refresh the subscription per the SIP Events 
Framework [RFC6665]. If the SUBSCRIBE request fails, then no 
Appearance Agent may be present and this feature is not active for 
this AOR. The UA MAY periodically retry the subscription to see if 
conditions have changed at intervals no shorter than four hours. 


Four hours was chosen to limit the subscription test to six per 
day per UA. Increasing this interval would reduce this failure 
traffic but take longer for a newly activated Appearance Agent to 
be discovered. 
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UAs can also use the presence of the 'shared' Event header field 
parameter in NOTIFYs to discover the presence of an Appearance Agent 
for the AOR. 


UAs that implement the shared appearances feature, call pickup, 
joining, and bridging MUST support sending an INVITE with Replaces 
[RFC3891] or Join [RFC3911]. The User Agent Client (UAC) needs to 
include the to-tag and from-tag information in the Replaces or Join 
header so that the correct dialog will be matched by the User Agent 
Server (UAS) per the rules in RFCs 3891 and 3911. 


All UAs that implement the shared appearances feature and support 
INVITE MUST support receiving an INVITE with a Replaces [RFC3891] or 
a Join [RFC3911] header field. 


When publishing or notifying dialog package information, a UA 
includes the largest set of dialog identification available at the 
time of publication, with the exception that a UA may omit 
information if it wishes to prevent other UAs from joining or picking 
up a call. Dialog identification includes local and remote target 
URIs, call-id, to-tag, and from-tag. While this dialog 
identification information is optional in [RFCA4235], it is essential 
in the shared appearances feature, allowing call control operations. 
When placing calls on hold, use the "+sip.rendering=no" feature tag 
to indicate this in dialog package notifications. Using the full SDP 
session description instead forces the endpoint to do a lot of extra 
parsing, unnecessarily complicating the code and inviting errors. 


The accurate rendering of the idle/active/alerting/hold state of 
other UAs in the group is an important part of the shared 
appearances feature. 


A UA that does not need to seize a particular appearance number (or 
doesn't care) would just send an INVITE as normal to place an 
outbound call. 


If the call is an emergency call, a UA MUST never wait for a 
confirmed seizure before sending an INVITE. Instead, the emergency 
call MUST proceed without waiting for the PUBLISH transaction. 


If a UA requires a particular appearance number, the a UA MUST send a 
dialog package PUBLISH request and wait for a 2xx response before 
sending the INVITE. This is required in the following situations: 


1. When the user seizes a particular appearance number for an 


outgoing call (e.g., seizing the appearance and going "off-hook", 
if the UA's user interface uses this metaphor). 
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2. When the user has requested that an appearance number not be used 
for an outgoing call (i.e., during a consultation call, a 
'service media' call such as for music on hold [RFC7088], or for 
a call not considered part of the shared appearance group). 


3. When the user has selected to join (or bridge) an existing call. 
4. When the user has selected to replace (or take) an existing call. 


Note that when a UA seizes an appearance prior to establishment of a 
dialog (numbers 1 and 2 in the above list), not all dialog 
information will be available. In particular, when a UA publishes an 
attempt to seize an appearance prior to knowing the destination URI, 
minimal or no dialog information may be available. For example, in 
Some cases, only the local target URI for the call will be known: not 
any dialog information. If the From tag and Call-ID were not present 
in the initial PUBLISH, a new PUBLISH MUST be sent as soon as this 
information is available. 


The first publication will cause the Appearance Agent to reserve 
the appearance number for this UA. If the publication does not 
have any dialog identifiers (e.g., Call-ID or local-tag), the 
Appearance Agent cannot assign the appearance number to a 
particular dialog of the UA until the second publication, which 
will contain some dialog identifiers. 


This publication state is refreshed as described in [RFC3903] during 
the early dialog state or the Appearance Agent may reassign the 
appearance number. Once the dialog has transitioned to the confirmed 
state, no publication refreshes are necessary. 


This specification assumes that the Appearance Agent has other 
means besides UA publication to learn about the state of UA 
dialogs. In this specification, PUBLISH is used to indicate 
desired and intended appearance number operations. Once a dialog 
transitions from early to confirmed, this role is over; hence, no 
publication refreshes are needed. 


Appearance numbers are a shorthand label for active and pending 
dialogs related to an AOR. Many of the features and services built 
using this extension rely on the correct rendering of this 
information to the human user. In addition, the group nature of the 
feature means that the rendering must be similar between different 
vendors and different models. Failure to do so will greatly reduce 
the value and usefulness of these protocol extensions. In a 
correctly designed user interface for this feature, the appearances 
number for each active and pending dialog is explicitly (i.e., by 
appearance number) or implicitly (using a user interface metaphor 
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that makes the numbering and ordering clear to the user) rendered to 
the user. The far-end identity of each dialog (e.g., the remote 
party identity) is not a useful replacement for the appearance 
number. The state of each appearance is also to be rendered (idle, 
active, busy, joined, etc.). UAs can tell that a set of dialogs are 
joined (bridged or mixed) together by the presence of one or more 
<joined-dialog> elements containing other SIP dialog identifiers. 
Appearance numbers of dialogs can be learned by dialog package 
notifications containing the «appearance» element from the Appearance 
Agent or from the 'appearance” Alert-Info parameter in an incoming 
INVITE. Should they conflict, the dialog package notification takes 
precedence. 


A user may select an appearance number but then abandon placing a 


call (go back on-hook). In this case, the UA frees up the appearance 
number by removing the event state with a PUBLISH as described in 
[RFC3903]. A failure to do this will require unnecessary operations 


by the Appearance Agent and tie up appearance numbers that could 
otherwise be used by other UAs in the shared appearance group. 


A UA SHOULD register against the AOR only if it is likely the UA will 
be answering incoming calls. If the UA is mainly going to be 
monitoring the status of the shared appearance group calls and 
picking or joining calls, the UA SHOULD only subscribe to the AOR and 
not register against the AOR. If a monitoring UA registers rather 
than just subscribing, it generates large amounts of unnecessary 
network traffic. 


All subscribed UAs will receive dialog package NOTIFYs of trying 
state for incoming INVITEs. 


A UA MUST NOT insert an 'appearance' parameter into an Alert-Info 
header field in an INVITE or other request. 


The Appearance Agent is solely responsible for doing this. 
5.3.1. Appearance Numbers and Call Context 


There are cases where two separate dialogs at a UA are not mixed but 
share the same 'context'. That is, they relate to each other and 
should not be treated the same as any other two dialogs within the 
group. One example of this is a 'consultation call’ where a user 
puts an existing dialog on hold, then calls another user, before 
switching back to the original dialog. Another case, described 
below, occurs during transfer operations, where for a transient 
period, a UA is involved in dialogs with two other UAs, but the 
dialogs are related, and should not be treated as independent 
dialogs. These cases are best handled by not assigning an appearance 
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number to a newly created dialog when it shares a context with an 
existing dialog. But if the preexisting dialog is terminated, its 
appearance number should be reassigned to the newly created dialog. 


A UA that wants to place a call but does not have an appearance 
number assigned sends a PUBLISH before sending the INVITE. The 
PUBLISH does not have an 'appearance' element present, but it does 
have the 'shared' Event header field parameter present. If the 
Appearance Agent policy does not allow calls without an assigned 
appearance number, a 400 (Bad Request) response is sent by the 
Appearance Agent and the UA will republish either selecting/seizing 
an appearance number or send the INVITE without publishing, in which 
case the Appearance Agent will assign one. 


Note that if an Appearance Agent rejects calls without an 
appearance number, certain operations such as consultation calls, 
transfer, and music on hold may be negatively impacted. 


5.3.2. Appearance Numbers and Call Control 


When an INVITE is generated to attempt to bridge or take a call 
(i.e., contains Join or Replaces with a dialog identifier of another 
dialog in the shared appearance group), the UA MUST first send a 
PUBLISH to the Appearance Agent. This PUBLISH will contain: 


1. The appearance number of the joined or replaced call in the 
«appearance» element 


2. The dialog information from the Join header field in the «joined- 
dialog» element, if the dialog is being joined 


3. The dialog information from the Replaces header field in the 
«replaced-dialog» element, if the dialog is being replaced 


Note that this information is provided to the Appearance Agent so 
that it can provide proper appearance assignment behavior. If the 
INVITE Join or Replaces was sent without publishing first, the 
Appearance Agent might assign a new appearance number to this 
INVITE, which would be a mistake. With Join, the publication has 
the «joined-dialog» element to prevent the Appearance Agent from 
generating a 400 (Bad Request) response due to the reuse of an 
appearance number. For Replaces, the purpose of the «replaced- 
dialog» is to prevent a race condition where the BYE could cause 
the appearance number to be released when it should stay with the 
replacing dialog. 
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5.3.3. Appearance Numbers and Transfer 


During a transfer operation, it is important that the appearance 
number not change during the operation. Consider the example of 
Alice, a member of a shared appearance group, who is talking to 
Carol, who is outside the shared appearance group. Carol transfers 
Alice to David, who is also outside the shared appearance group. For 
example, if Alice is using appearance 3 for the session with Carol, 
the resulting session with David should also use appearance number 3. 
Otherwise, an appearance number change can cause a "jump" on the UI 
and confusion to the user. There are two possible scenarios using 
the terminology of RFC 5589: Alice is the transferee in any type of 
transfer (receives the REFER) or the transfer target in an attended 
transfer (receives the INVITE with Replaces). 


If Alice is the transferee, the triggered INVITE from the REFER is 
treated as a consultation call. Alice SHOULD publish requesting that 
the Appearance Agent not assign an appearance number for this INVITE. 
When the transfer completes, Alice SHOULD publish again to move the 
appearance number from the dialog with Carol to the dialog with 
David. If a PUBLISH is sent to move the appearance number, the 
publication MUST be sent prior to sending the BYE to Carol to avoid a 
race condition where the Appearance Agent reassigns the appearance 
number after seeing the BYE. 


If Alice is the target, the incoming INVITE will contain a Replaces 
header field. As a result, the Appearance Agent will have reused the 
appearance number of the dialog with Carol, and this appearance 
number will continue to be used after the dialog with Carol has been 
terminated. 


5.4. Appearance Agent 


An Appearance Agent defined in this specification MUST implement a 
dialog package state agent for the UAs registered against the AOR. 
The Appearance Agent MUST support the appearance dialog package 
extensions defined in Section 5.2 and use the 'shared' Event header 
field parameter. The Appearance Agent MUST support publications and 
subscriptions for this event package. 


The Appearance Agent MUST have a way of discovering the state of all 
dialogs associated with the AOR. If this information is not 
available from a call stateful proxy or Back-to-Back User Agent 
(B2BUA), the Appearance Agent can use the registration event package 
[RFC3680] to learn of UAs associated with the AOR and subscribe to 
their dialog event state. An Appearance Agent can also subscribe to 
a UA's dialog event state in order to reconstruct state. As a 
result, the registrar MUST support the registration event package. 
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Dialog package notifications are recommended by RFC 4235 to "only 
contain information on the dialogs whose state or participation 
information has changed." This specification extends RFC 4235 as 
follows. The Appearance Agent SHOULD send dialog event state 
notifications whenever the following events happen to UAs in the AOR 
group: 


1. A call is received, placed, answered, or terminated. 
2. A call is placed on or off hold. 
3. A call is joined or replaced. 


4. An appearance number is reserved or released. 


The Appearance Agent MUST allocate an appearance number for all 
incoming calls and send immediate notifications to the UAs subscribed 
to the shared group AOR. A new appearance number is allocated except 
for an incoming INVITE with a Join or Replaces header field. For 
this case, the appearance number should match the appearance number 
of the dialog being joined or replaced. If the INVITE Replaces or 
Join comes from outside the shared appearance group, the Appearance 
Agent will include a <joined-dialog> or <replaced-dialog> element in 
the NOTIFY containing the dialog information from the Replaces or 
Joined header field. 


The Appearance Agent MUST be able to communicate with the forking 
proxy to learn about incoming calls and also to pass the appearance 
number to the proxy or ensure the Alert-Info header field is included 
in the INVITE with the appropriate appearance number. 


Note that UAs need to be able to handle incoming INVITEs without 
an appearance number assigned. This could be caused by a failure 
of the Appearance Agent or other error condition. Although the 
proper rendering of the INVITE may not be possible, this is better 
than ignoring or failing the INVITE. 


An Appearance Agent SHOULD assign an appearance number to an outgoing 
dialog if a PUBLISH has not been received selecting/seizing a 
particular appearance number. 


Note that if the shared appearance group has appearance-unaware 
UAs making calls, the Appearance Agent will still allocate 
appearance numbers for INVITEs sent by those UAs. 


An Appearance Agent receiving a PUBLISH with an appearance number 


checks to make sure the publication is valid. An appearance number 
can be assigned to only one dialog unless there is a <joined-dialog> 
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or «replaced-dialog» element indicating that the dialog will be/has 
been replaced or joined. A 400 (Bad Request) response is returned if 
the chosen appearance number is invalid, and an immediate NOTIFY 
SHOULD be sent to the UA containing full dialog event state. 


An Appearance Agent receiving a PUBLISH without an appearance number 
but with the 'shared' Event header field parameter present interprets 
this as a request by the UA to not assign an appearance number. If 
the Appearance Agent policy does not allow this, a 400 (Bad Request) 
response is returned. If policy does allow this, a 200 (OK) response 
is returned and no appearance number is allocated. An Appearance 
Agent does not have to share this dialog information (i.e., send a 
NOTIFY) with other UAs in the group as the information will not be 
rendered by the other UAs. 


The Appearance Agent allocates an appearance number to a dialog from 
the time the appearance is requested via a PUBLISH or from the 
receipt of an INVITE to the time when the last dialog associated with 
the appearance is terminated, including all dialogs that are joined 
or replaced. During the early dialog state, the Appearance Agent 
controls the rate of dialog state publication using the Expires 
header field in 200 (OK) responses to PUBLISH requests. An interval 
of 3 minutes is RECOMMENDED. After the dialog associated with the 
publication has been confirmed, the expiration of the publication 
state has no effect on the appearance allocation. If the publication 
contains no dialog state information, the Appearance Agent MUST 
reserve the appearance number for the UA but cannot assign the 
appearance to any particular dialog of the UA. When the publication 
state is updated with any dialog information, the appearance number 
can then be assigned to the particular dialog. A UA that has been 
allocated an appearance number using a PUBLISH MAY free up the 
appearance number by removing the event state with a PUBLISH as 
described in [RFC3903]. 


If an INVITE is sent by a member of the group to the shared AOR 
(i.e., they call their own AOR), the Appearance Agent MUST assign two 
appearance numbers. The first appearance number will be the one 
selected or assigned to the outgoing INVITE. The second appearance 
number will be another one assigned by the Appearance Agent for the 
INVITE as it is forked back to the members of the group. 


The is to preserve a common behavior in legacy systems. 
If an INVITE is sent by a member of the group using the shared AOR or 


sent to the shared AOR and no appearance number is available, the 
proxy MAY reject the INVITE with a 403 (Forbidden) response code. 
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Appearance numbers are only used for dialogs in which one or more UAs 
associated with the group AOR are participants. If an incoming 
INVITE to the group AOR is forwarded to another AOR, the appearance 
number is immediately freed up and can be assigned to another dialog. 


6. XML Schema Definition 


The 'appearance', 'joined-dialog', 'replaced-dialog', and 'exclusive' 
elements are defined within a new XML namespace URI. This namespace 


is "urn:ietf:params:xml:ns:sa-dialog-info". The schema for these 
elements is: 
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<?xml version="1.0" encoding-"UTF-8"?» 

«xs:schema 
targetNamespace-"urn:ietf:params:xml:ns:sa-dialog-info" 
xmlns-"urn:ietf:params:xml:ns:sa-dialog-info" 
xmlns:xs-"http://www.w3.org/2001/XMLSchema" 
elementFormDefault="qualified"> 


<xs:element name-"joined-dialog" minOccurs="0" 
maxOccurs="unbounded"> 
<xs:complexType> 
«xs:attribute name-"call-id" type-"xs:string" 
use-"mandatory"/» 
«xs:attribute name-"local-tag" type="xs:string" 
use-"mandatory"/» 
«xs:attribute name-"remote-tag" type-"xs:string" 
use-"mandatory"/» 
«/xs:complexType» 
</xs:element> 


<xs:element name="replaced-dialog" minOccurs="0" 
maxOccurs-"unbounded"» 
<xs:complexType> 
«xs:attribute name-"call-id" type="xs:string" 
use-"mandatory"/» 
«xs:attribute name-"local-tag" type="xs:string" 
use-"mandatory"/» 
«xs:attribute name-"remote-tag" type-"xs:string" 
use-"mandatory"/» 
«/xs:complexType» 
«/xs:element» 


<xs:element name-"appearance" minOccurs="0" maxOccurs="1"> 
<xs:simpleType type="xs:integer"> 
</xs:simpleType> 

</xs:element> 


<xs:element name-"exclusive" minOccurs="0" maxOccurs="1"> 
<xs:simpleType type="xs:boolean"> 
</xs:simpleType> 
</xs:element> 
</xs:schema> 
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7. 


Alert-Info Appearance Parameter Definition 
This specification extends [RFC3261] to add an 'appearance' parameter 
to the Alert-Info header field and also to allow proxies to modify or 


delete the Alert-Info header field. 


The changes to the ABNF [RFC5234] in RFC 3261 are: 


LAQUOT absoluteURI RAQUOT *( SEMI 
(generic-param / appearance-param) ) 
appearance-param - "appearance" EQUAL 1*DIGIT 


alert-param 


A proxy inserting an 'appearance' Alert-Info parameter follows normal 
Alert-Info policies. To indicate the appearance number for this 
dialog, the proxy adds the Alert-Info header field with the 
‘appearance’ parameter to the INVITE. If an Alert-Info is already 
present, the proxy adds the 'appearance' parameter to the Alert-Info 
header field. If an appearance number parameter is already present 
(associated with another AOR or by mistake), the value is rewritten 
adding the new appearance number. There MUST NOT be more than one 
appearance parameter in an Alert-Info header field. 


If no special ringtone is desired, a normal ringtone SHOULD be 
indicated using the urn:alert:service:normal in the Alert-Info, as 
per [RFC7462]. The appearance number present in an Alert-Info header 
field SHOULD be rendered by the UA to the user, following the 
guidelines in Section 5.3. If the INVITE is forwarded to another 
AOR, the appearance parameter in the Alert-Info SHOULD be removed 
before forwarding outside the group. 


The determination as to what value to use in the appearance parameter 
can be done at the proxy that forks the incoming request to all the 
registered UAs. 


There is a variety of ways the proxy can determine what value it 
should use to populate this parameter. For example, the proxy 
could fetch this information by initiating a SUBSCRIBE request 
with Expires: 0 to the Appearance Agent for the AOR to fetch the 
list of lines that are in use. Alternatively, it could act like a 
UA that is a part of the shared appearance group and SUBSCRIBE to 
the State-Agent like any other UA. This would ensure that the 
active dialog information is available without having to poll on a 
need basis. It could keep track of the list of active calls for 
the appearance AOR based on how many unique INVITE requests it has 
forked to or received from the appearance AOR. Another approach 
would be for the Proxy to first send the incoming INVITE to the 
Appearance Agent, which would redirect to the shared appearance 
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8. 


8. 


8. 


8. 


group URI and escape the proper Alert-Info header field for the 
Proxy to recurse and distribute to the other UAs in the group. 


The Appearance Agent needs to know about all incoming requests to 
the AOR in order to seize the appearance number. One way in which 
this could be done is for the Appearance Agent to register against 
the AOR with a higher q value. This will result in the INVITE 
being sent to the Appearance Agent first, then being offered to 
the UAs in the group. 


User Interface Considerations 


The appearance number allocated to a call is an important concept 
that enables calls to be handled by multiple devices with 
heterogeneous user interfaces in a manner that still allows users to 
See a consistent model. Careful treatment of the appearance number 
is essential to meet the expectations of the users. Also, rendering 
the correct call/appearance state to users is also important. 


1. Appearance Number Rendering 


Since different UAs have different user interface capabilities, it is 
usual to find that some UAs have restrictions that others do not. 
Perfect interoperability across all UAs is clearly not possible, but 
by careful design, interoperability up to the limits of each UA can 
be achieved. 


The following guidelines suggest how the appearance number should be 
handled in three typical user interface implementations. 


1.1. Single Appearance UAs 


These devices are constrained by only having the capability of 
displaying status indications for a single appearance. The UA SHOULD 
Still send messages annotated with appearance number "1". Any call 
indications for appearances other than for number "1" SHOULD be 
rejected with a 480 (Temporarily Unavailable) or 486 (Busy Here) 
response. Note that this means that a single appearance UA cannot 
answer its own call to the shared AOR, since this call would use a 
Second appearance number. 


1.2. Dual Appearance UAs 


These devices are essentially single appearance phones that implement 
call waiting. They have a very simple user interface that allows 
them to switch between two appearances (toggle or flash hook) and 
perhaps audible tones to indicate the status of the other appearance. 
Only appearance numbers "1" and "2" will be used by these UAs. 
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8.1.3. Shared Appearance UAs with Fixed Appearance Number 


This UA is the typical 'business-class' hard-phone. A number of 
appearances are typically configured statically and labeled on 
buttons, and calls may be managed using these configured appearances. 
Any calls outside this range should be rejected, and not mapped to a 
free button. Users of these devices often seize specific appearance 
numbers for outgoing calls, and the UA will need to seize the 
appearance number and wait for confirmation from the Appearance Agent 
before proceeding with calls. 


8.1.4. Shared Appearance UAs with Variable Appearance Numbers 


This UA is typically a soft-phone or graphically rich user interface 
hard-phone. In these cases, even the idea of an appearance index may 
Seem unnecessary. However, for these phones to be able to interwork 
successfully with other phone types, it is important that they still 
use the appearance index to govern the order of appearance of calls 
in progress. No specific guidance on presentation is given except 
that the order should be consistent. These devices can typically 
make calls without waiting for confirmation from the Appearance Agent 
on the appearance number. 


8.1.5. Example User Interface Issues 


The problems faced by each style of user interface are readily seen 
in this example: 


1. A call arrives at the shared appearance group and is assigned an 
appearance number of "1". All UAs should be able to render to 
the user the arrival of this call. 


2. Another call arrives at the shared appearance group and is 
assigned an appearance number of "2". The single appearance UA 
should not present this call to the user. Other UAs should have 
no problems presenting this call distinctly from the first call. 


3. The first call clears, releasing appearance number "1". The 
single appearance UA should now be indicating no calls since it 
is unable to manage calls other than on the first appearance. 
Both shared appearance UAs should clearly show that appearance 
number "1" is now free, but that there is still a call on 
appearance number "2". 


4. A third call arrives and is assigned the appearance number of 
"1", All UAs should be able to render the arrival of this new 
call to the user. Multiple appearance UAs should continue to 
indicate the presence of the second call, and they should also 
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ensure that the presentation order is related to the appearance 
number and not the order of call arrival. 


8.2. Call State Rendering 


UAs that implement the shared appearances feature typically have a 
user interface that provides the state of other appearances in the 
group. As dialog state NOTIFYs from the Appearance Agent are 
processed, this information can be rendered. Even the simplest user 
interface typically has three states: idle, active, and hold. The 
idle state, usually indicated by lamp off, is indicated for an 
appearance when the appearance number is not associated with any 
dialogs, as reported by the Appearance Agent. The active state, 
usually indicated by a lamp on, means that an appearance number is 
associated with at least one dialog, as reported by the Appearance 
Agent. The hold state, often indicated by a blinking lamp, means the 
call state from the perspective of the UA in the shared appearance 
group is hold. This can be determined by the presence of the 
"+sip.rendering=no" feature tag [RFC3840] with the local target URI. 
Note that the hold state of the remote target URI is not relevant to 
this display. For joined dialogs, the state is rendered as hold only 
if all local target URIs are indicated with the "+sip.rendering=no" 
feature tag. 


9. Interoperability with Non-shared Appearance UAs 


It is desirable to allow a basic UA that does not directly support 
shared appearance to be part of a shared appearance group. To 
support this, the Proxy must collaborate with the Appearance Agent. 
This is not required in the basic shared appearance architecture; 
consequently, shared appearance interoperability with non-shared 
appearance UAs will not be available in all shared appearance 
deployments. 


First, a UA that does not support dialog events or the shared 
appearances feature will be discussed. Then, a UA that does support 
dialog events but not the shared appearances feature will be 
discussed. 


9.1. Appearance Assignment 


A UA that has no knowledge of appearances will only have appearance 
numbers for outgoing calls if assigned by the Appearance Agent. If 
the non-shared appearance UA does not support Join or Replaces, all 
dialogs SHOULD be marked "exclusive" to indicate that these options 
are not available. Marking these dialogs "exclusive" provides a 
better user experience and avoids extra SIP messaging failures. 
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2. Appearance Release 


In all cases, the Appearance Agent must be aware of the dialog 
lifetime to release appearances back into the group. 


It is also desirable that any dialog state changes (such as hold, 
etc.) be made available to other UAs in the group through the Dialog 
Event Package. If the Appearance Agent includes a proxy that Record- 
Routes for dialogs from the non-shared-appearance-aware UA, the 
Appearance Agent will know about the state of dialogs including hold, 
etc. This information could be determined from inspection of non- 
end-to-end-encrypted INVITE and re-INVITE messages and added to the 
dialog information conveyed to other UAs. 


3. UAs Supporting Dialog Events but Not Shared Appearance 


Interoperability with UAs that support dialog events but not the 
shared appearances feature is more straightforward. As before, all 
appearance number assignments must be done by the Appearance Agent. 
The Appearance Agent SHOULD still include appearance information in 
NOTIFYs -- this UA will simply ignore this extra information. This 
type of UA will also ignore appearance number limitations and may 
attempt to join or replace dialogs marked exclusive. As a result, 
the Proxy or UAs need to reject such requests or the dialogs will be 
joined or taken. 


Provisioning Considerations 


UAs can automatically discover if this feature is active for an AOR 
by looking for the 'shared' Event header field parameter in a 
response to a dialog package SUBSCRIBE to the AOR, so no provisioning 
for this is needed. 


The registrar will need to be provisioned to accept either first or 
third party registrations for the shared AOR. First party 
registration means the To and From URIs in the REGISTER request are 
the shared AOR URI.  Third-party registration means the To URI is the 
shared AOR URI and the From URI is a different AOR, perhaps that of 
the individual user. Either the credentials of the shared AOR or the 
user MUST be accepted by the registrar and the Appearance Agent, 
depending on the authorization policy in place for the domain. 


If the Appearance Agent needs to subscribe to the dialog state of the 
UAs, then the Appearance Agent and the UAs need to be provisioned 
with credentials so the UAs can authenticate the Appearance Agent. 


In some cases, UAs in the shared appearance group might have a UI 
limitation on the number of appearances that can be rendered. 
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Typically, this will be hard-phones with buttons/lamps instead of 
more flexible UIs. In this case, it can be useful for the Appearance 
Agent to know this maximum number. This can allow the Appearance 
Agent to apply policy when this limit is reached, e.g., deny a call. 
However, this mechanism does not provide any way to discover this by 
protocol means. 


11. Example Message Flows 


The next section shows call flow and message examples. The flows and 
descriptions are non-normative. Note that, in these examples, all 
INVITEs sent by a UA in the group will be From the shared AOR 
(sip:HelpDesk@example.com in this case), and all INVITES sent to the 
group will have a Request-URI of the shared AOR. Any other requests 
would not apply to this feature and would be handled using normal SIP 
mechanisms. 


Note that the first 12 examples assume the Appearance Agent is aware 
of dialog state events. The example in Section 11.13 shows the case 
where this is not the case, and, as a result, the Appearance Agent 
initiates a subscription to users of the shared AOR. Any of the 
other call flow examples could have shown this mode of operation as 
it is equally valid. 


11.1. Registration and Subscription 


Bob and Alice are in a shared appearance group identified by the 
shared appearance AOR sip:HelpDesk@example.com. Bob REGISTERS using 
contact sip:bob@ua2.example.com. Alice REGISTERs with contact 
sip:alice@ual.example.com. 


UAs for Alice and Bob subscribe to the dialog package for the 
appearance AOR and publish dialog state to the Appearance Agent. 
Message exchanges between the Registrar, Appearance Agent, Alice, and 
Bob are shown below. The call flow examples below do not show the 
authentication of subscriptions, publications, and notifications. It 
should be noted that for security purposes, all publications and 
subscriptions must be authorized before they are accepted. 


Also note that registrations and subscriptions must all be refreshed 
by Alice at intervals determined by the expiration intervals returned 
by the Registrar or Appearance Agent. 


Registrar Appearance Agent Alice Bob 


<--------------------------- REGISTER F1< 
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A OS OURISSI > | 
| F RN SUBSCRIBE "T 
| |»F4 200 OK -------- >| 

| es NOTIFY: 225522 ‘| | 
| l = 200 OK idea | 
ORI UD PS SEDES SOUS REGISTER F7«| 
E 200 OK HMM ee | ae | 
e e SUBSCRIBE a 
| >F10 200 OK muse di DINERS " 
| br NOTIFY PS IA s 
(A 200 OK nae 


Figure 1. Registration and Subscription Example 


F1-F2: Alice registers AOR with 
contact: <sip:alice@ual.example.com> 


F1 Alice ----> Registrar 


REGISTER sip:registrar.example.com SIP/2.0 

Via: SIP/2.0/UDP ual.example.com;branch-z9hG4bK527b54da8ACC7B09 
From: <sip:alice@example.com>; tag=CDF9A668-909E2BDD 

To: <sip:HelpDesk@example.com> 

CSeq: 2 REGISTER 

Call-ID: d3281184-518783de-cc23d6bb 

Contact: <sip:alice@ual.example.com> 

Max-Forwards: 70 

Expires: 3600 

Content-Length: 0 


F2 Registrar ----» Alice 
SIP/2.0 200 OK 
Via: SIP/2.0/UDP ual.example.com; branch=z9hG4bK527b54da8ACC7B09 


CSeq: 2 REGISTER 
Call-ID: d3281184-518783de-cc23d6bb 
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From: <sip:alice@example.com>; tag=CDF9A668-909E2BDD 
To: <sip:HelpDesk@example.com>; tag=1664573879820199 
Contact: <sip:alice@ual.example.com>;expires=3600 
Content-Length: 0 


F3 to F6: Alice also subscribes to the events associated with the 
Appearance AOR. Appearance Agent notifies Alice of the status. 


F3 Alice ----» Appearance Agent 


SUBSCRIBE sip:HelpDesk@example.com SIP/2.0 

Via: SIP/2.0/UDP ual.example.com;branch-z9hG4bKfl0fac97E7A76D6A 
From: <sip:alice@example.com>; tag=925A3CAD-CEBB276E 
To: <sip:HelpDesk@example.com> 

CSeq: 91 SUBSCRIBE 

Call-ID: ef4704d9-bb68aa0b-474c9d94 

Contact: <sip:alice@ual.example.com> 

Event: dialog;shared 

Accept: application/dialog-info+xml 

Max-Forwards: 70 

Expires: 3700 

Content-Length: 0 


F4 Appearance Agent ----> Alice 


SIP/2.0 200 OK 

Via: SIP/2.0/UDP ual.example.com;branch-z9hGA4bKfl0fac97E7A76D6A 
CSeq: 91 SUBSCRIBE 

Call-ID: ef4704d9-bb68aa0b-474c9d94 

From: <sip:alice@example.com>; tag=925A3CAD-CEBB276E 

To: <sip:HelpDesk@example.com>; tag=1636248422222257 
Allow-Events: dialog 

Expires: 3700 

Contact: «sip:appearanceagent.example.com» 

Content-Length: 0 


F5 Appearance Agent ----> Alice 


NOTIFY sip:aliceQual.example.com SIP/2.0 

From: <sip:HelpDesk@example.com>; tag=1636248422222257 

To: <sip:alice@example.com>; tag=925A3CAD-CEBB276E 

Call-ID: ef4704d9-bb68aa0b-474c9d94 

CSeq: 232 NOTIFY 

Via: SIP/2.0/UDP appearanceagent.example.com; branch=z9hG4bK1846 
Max-Forwards: 70 
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Content-Type: application/dialog-info+xml 
Event: dialog;shared 

Subscription-State: active;expires-3000 
Contact: «sip:appearanceagent.example.com» 
Content-Length: 


«?xml version="1.0"?> 

«dialog-info xmlns-"urn:ietf:params:xml:ns:dialog-info" 
version="40" 
state="full" 
entity="sip:HelpDesk@example.com"> 

</dialog-info> 


F6 Alice ----» Appearance Agent 


SIP/2.0 200 OK 

Via: SIP/2.0/UDP appearanceagent.example.com; branch=z9hG4bK1846 
From: <sip:HelpDesk@example.com>; tag=1636248422222257 

To: <sip:alice@example.com>; tag=925A3CAD-CEBB276E 

CSeq: 232 NOTIFY 

Call-ID: ef4704d9-bb68aa0b-474c9d94 

Contact: <sip:alice@ual.example.com> 

Content-Length: 0 


F7 Bob ----» Registrar 


REGISTER sip:registrar.example.com SIP/2.0 

Via: SIP/2.0/UDP ua2.example.com; branch=z9hG4b53b54d87B 
From: «sip:bobGexample.com»;tag-34831131 

To: <sip:HelpDesk@example.com> 

CSeq: 72 REGISTER 

Call-ID: 139490230230249348 

Contact: <sip:bob@ua2.example.com> 

Max-Forwards: 70 

Expires: 3600 

Content-Length: 0 


F8 Registrar ----» Bob 


SIP/2.0 200 OK 

Via: SIP/2.0/UDP ua2.example.com; branch=z9hG4b53b54d87B 
From: «sip:bobGexample.com»;tag-34831131 

To: <sip:HelpDesk@example.com>;tag=fkwlwqil 

CSeq: 72 REGISTER 

Call-ID: 139490230230249348 
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Contact: <sip:alice@ual.example.com>; expires=3200 
Contact: <sip:bob@ua2.example.com>;expires=3600 
Content-Length: 0 


11.2. Appearance Selection for Incoming Call 


In the call flow below, Bob and Alice are in a shared appearance 
group. Carol places a call to the shared appearance group AOR. The 
Appearance Agent sends NOTIFYs to Alice and Bob telling them what 
appearance the call is using. Both Alice and Bob’s devices are 
alerted of the incoming call. Bob answers the call. 


Note that it is possible that both Alice and Bob answer the call and 
send 200 (OK) responses to Carol. It is up to Carol to resolve this 
situation. Typically, Carol will send ACKs to both 200 OKs but send 
a BYE to terminate one of the dialogs. As a result, either Alice or 
Bob will receive the BYE and publish that their dialog is over. 
However, if Carol answers both Alice and Bob and keeps both dialogs 
active, then the Appearance Agent will need to resolve the situation 
by moving either Alice or Bob’s dialog to a different appearance. 


All NOTIFY messages in the call flow below carry dialog events and 
only dialog states are mentioned for simplicity. For brevity, the 
details of some messages are not shown below. Note that the order of 
F2 - F5 and F7 - F8 could be reversed. 


Forking Appearance 
catol Proxy Agent Alice Bob 
|>F1 INVITE >| | | | 
GS > 
>F2 NOTIFY ----------- > 
| | 
|<F3 200 OK ----------- p 


| 
| 
| |>F4 NOTIFY ->| 


| 

| 

| 

| 

| «-200 OK F5-« 
|«- 100 F6 -«| | | 
| |>F7 INVITE (appearance-1) ---------- > 
| 

| 


|>F8 INVITE (appearance=1) >| 


Lea a Ringing 180 F9< 
< 180 F10 -«| | | | 
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|«--------- 180 Ringing F11«| 
|< 180 F12 -<| | | 


RN OE NE 200 OK F13< 
« 200 F14 -«| | | 
| | 
|>F15 CANCEL -------------- >| 
| | 
lt 200 OK F16< 


|<Request Cancelled 487 F17«| 


| 
[SETE ACK ----------------- >| 
| 


>F19 ACK --»| 
|>F20 ACK --------------------------- > 
| | | 

< Both way RIP established===========> 


>F21 NOTIFY > 


|>F23 NOTIFY ---------- > 


|<F24 200 OK ---------- < 


Figure 2. Appearance Selection for Incoming Call Example 


| 
| 
| 
| 
| <- 200 F22 -< 
| 
| 
| 
| 
| 


F4 Appearance Agent ----> Alice 


NOTIFY sip:aliceQual.example.com SIP/2.0 

From: <sip:HelpDeskfexample.com>;tag=151702541050937 
To: <sip:alice@example.com>; tag=18433323-C3D237CE 
Call-ID: 1le361d2f-a9f51109-bafe31d4 

CSeq: 12 NOTIFY 


March 2015 


Via: SIP/2.0/UDP appearanceagent.example.com;branch-z9hG4bK1403 


Max-Forwards: 70 

Content-Type: application/dialog-info+xml 
Event: dialog;shared 

Subscription-State: active;expires-2800 
Contact: «sip:appearanceagent.example.com» 
Content-Length: 


<?xml version="1.0"?> 
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«dialog-info xmlns-"urn:ietf:params:xml:ns:dialog-info" 
xmlns:sa-"urn:ietf:params:xml:ns:sa-dialog-info" 


version="13" 
state="partial" 
entity="sip:HelpDesk@example.com"> 


«dialog id="2a7294823093f5274e3fd2ec54a2d76c" 


call-id="14-1541707345" 
remote-tag="44BAD75D-E3128D42" 
direction="recipient"> 
<sa:appearance>1</sa:appearance> 
<state>trying</state> 
<remote> 
<identity>sip:carol@ua.example.com</identity> 
</remote> 


</dialog> 
</dialog-info> 


F7 Proxy ----» Bob 


INVITE sip:bob@ua2.example.com SIP/2.0 
Via: SIP/2.0/UDP ua3.example.com;branch-z9hG4bK4324ea 


Via: SIP/2.0/UDP proxy.example.com;branch-z9hG4bK38432ji 


From: 


«sip:carolGüexample.com»;tag-44BAD75D-E3128D42 


To: <sip:HelpDesk@example.com> 


CSeq: 


106 INVITE 


Call-ID: 14-1541707345 
Contact: <sip:carol@ua3.example.com> 
Max-Forwards: 69 


Alert- 


Info: <urn:alert:service:normal>; appearance=1 


Content-Type: application/sdp 
Content-Length: 


v=0 


o-- 1102980499 1102980499 IN IP4 ua3.example.com 


s= 


C-IN IP4 ua3.example.com 


t=0 0 


m-audio 2238 RTP/AVP 0 8 101 
a=rtpmap:0 PCMU/8000 

a=rtpmap:8 PCMA/8000 

a=rtpmap:101 telephone-event/8000 


F21 Appearance Agent ----> Alice 


NOTIFY sip:aliceQual.example.com SIP/2.0 


From: 


Johnston, 


<sip:HelpDesk@example.com>; tag=151702541050937 
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To: <sip:alice@example.com>; tag=18433323-C3D237CE 

Call-ID: 1le361d2f-a9f51109-bafe31d4 

CSeq: 13 NOTIFY 

Via: SIP/2.0/UDP appearanceagent.example.com;branch-z9hG4bK4164F03j 
Max-Forwards: 70 

Content-Type: application/dialog-info+xml 

Event: dialog;shared 

Subscription-State: active;expires-2500 

Contact: <sip:appearanceagent.example.com> 

Content-Length: 


<?xml version="1.0"?> 
<dialog-info xmlns-"urn:ietf:params:xml:ns:dialog-info" 
xmlns:sa-"urn:ietf:params:xml:ns:sa-dialog-info" 
version="17" 
state-"partial" 
entity="sip:HelpDesk@example.com"> 
«dialog id="2a7294823093f5274e3fd2ec54a2d76c" 
call-id="14-1541707345" 
remote-tag="44BAD75D-E3128D42" 
local-tag=""7349dsf3jkFDO3s" 
direction="recipient"> 
<sa:appearance>1</sa:appearance> 
<state>confirmed</state> 
<local> 
<target>sip:bob@ua2.example.com</target> 
</local> 
<remote> 
<identity>sip:carol@ua.example.com</identity> 
</remote> 
</dialog> 
</dialog-info> 


11.3. Outgoing Call without Appearance Seizure 


In this scenario, Bob’s UA places a call without first selecting/ 
seizing an appearance number. After Bob sends the INVITE, the 
appearance assigns an appearance number for it and notifies both 
Alice and Bob. 


Carol Proxy Alice Appearance Agent Bob 
| | | | | 
| | | | | 
<------------------------------------- INVITE F1< 
| | 
| |>F2 100 Trying --------------------------------- > | 
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«-- INVITE F3«| | | 
| 


| 
| eU OS e RE rcd ee > 
| | «-- NOTIFY F4< | 
| | | | | 
| | |>F5 200 OK -->| | 
| | | |------- NOTIFY F6»| 
| | | | 
«F7 200 OK ------ < 

>F8 180  ----> 

>F9 180 Ringing -------------------------------- > 


^ 
| 
| 
l 
| 
l 
| 
l 
| 
| 
l 
| 
l 
| 
l 

v 


|<- NOTIFY F10< 


| 

| 

| 

| 

| 

>F11 200 OK -> | 
|------ NOTIFY F12>| 

| 

| 

| 


| 
| |<F13 200 OK ----- < 
| 


>F14 200 OK -> 
>F15 200 OK ------------------------------------— > 
| 
«---- ACK F17<| | | 
| | | 
< Both way RTP established > 
| 
«—-------------c- > 
| 


|<- NOTIFY F18<| 


| 
| 
| |>F19 200 OK ->| 

| IR NOTIFY F20> 
| 

| 


| 
| 
| 
| 
| 
| 
| 
| | La ACK F16<| 
| 
| 
| 
| 
| 
| 
| 


| |<F21 200 OK ----- «| 
| | 


Figure 3. Outgoing Call without Appearance Seizure Example 


F1 Bob ----» Proxy 


INVITE sip:carol@example.com SIP/2.0 

Via: SIP/2.0/UDP ua2.example.com;branch-z9hG4bK98c87c52123A08BF 
From: <sip:HelpDesk@example.com>; tag=15A3DE7C-9283203B 

To: <sip:carol@example.com> 

CSeq: 1 INVITE 
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Call-ID: f3b3cbd0-a2c5775e-5df9f8d5 
Contact: <sip:bob@ua2.example.com> 
Max-Forwards: 70 

Content-Type: application/sdp 
Content-Length: 223 


v=0 

o=- 1102980499 1102980499 IN IP4 ua2.example.com 
s=IP SIP UA 

C-IN IP4 ua2.example.com 

t-0 0 

a-sendrecv 

m-audio 2236 RTP/AVP 0 8 101 

a-rtpmap:0 PCMU/8000 

a-rtpmap:8 PCMA/8000 

a-rtpmap:101 telephone-event/8000 


F4 Appearance Agent ----> Alice 


NOTIFY sip:alice@ual.example.com SIP/2.0 

Via: SIP/2.0/UDP appearanceagent.example.com; branch=z9hG4bK81d84f62 
From: <sip:HelpDesk@example.com>; tag=1636248422222257 
To: <sip:alice@example.com>; tag=925A3CAD-CEBB276E 
Call-ID: ef4704d9-bb68aa0b-474c9d94 

CSeq: 233 NOTIFY 

Max-Forwards: 70 

Content-Type: application/dialog-info+xml 

Event: dialog;shared 

Subscription-State: active;expires-2200 

Contact: <sip:appearanceagent.example.com> 
Content-Length: 


<?xml version="1.0"?> 
<dialog-info xmlns-"urn:ietf:params:xml:ns:dialog-info" 
xmlns:sa-"urn:ietf:params:xml:ns:sa-dialog-info" 
version="27" 
state="partial" 
entity="sip:HelpDesk@example.com"> 
«dialog id="f£a02538339df3ce597£9e3e3699e28fc" 
call-id-"f3b3cbd0-a2c5775e-5df9f8d5" 
local-tag="15A3DE7C-9283203B" direction="initiator"> 
<sa:appearance>1</sa:appearance> 
<sa:exclusive>false</sa:exclusive> 
<state>trying</state> 
<local> 
«target uri="sip:bob@ua2.example.com"> 
</target> 
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</local> 
</dialog> 
</dialog-info> 
F6 Appearance Agent ----> Bob 


NOTIFY sip:bob@ual.example.com SIP/2.0 

From: <sip:HelpDesk@example.com>; tag=497585728578386 

To: <sip:bob@example.com>; tag=633618CF-B9C2EDA4 

Call-ID: a7d559db-d6d7dcad-311c9e3a 

CSeq: 7 NOTIFY 

Via: SIP/2.0/UDP appearanceagent.example.com 
;branch-z9hG4bK1711759878512309 

Max-Forwards: 70 

Content-Type: application/dialog-info+xml 

Event: dialog;shared 

Subscription-State: active;expires-2000 

Contact: <sip:appearanceagent.example.com> 

Content-Length: 


<?xml version="1.0"?> 
<dialog-info xmlns-"urn:ietf:params:xml:ns:dialog-info" 
xmlns:sa-"urn:ietf:params:xml:ns:sa-dialog-info" 
version="78" 
state="partial" 
entity="sip:HelpDesk@example.com"> 
«dialog id-2"02538339hfgdf3ce597f9e3egkl13699e28fc" 
call-id-"f3b3cbd0-a2c5775e-5df9f8d5" 
local-tag="15A3DE7C-9283203B" direction="initiator"> 
<sa:appearance>1</sa:appearance> 
<sa:exclusive>false</sa:exclusive> 
<state>trying</state> 


<local> 
«target uri="sip:bob@ua2.example.com"> 
</target> 
</local> 
</dialog> 
</dialog-info> 
4. Outgoing Call with Appearance Seizure 


In this scenario, Bob's UA sends out a dialog event PUBLISH with 


2015 


state (trying) selecting/seizing an appearance number before sending 
the INVITE. After receiving the 200 (OK) from the Appearance Agent 
confirming the appearance number, Bob's UA sends the INVITE to Carol 


and establishes a session. For brevity, details of some of the 


messages are not included in the message flows. Bob's UA puts as 
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much of the dialog information from F7 as can be determined in 


advance. In this case, the minimum of the Contact URI is included, 

which allows the Appearance Agent to correlate the INVITE with the 

PUBLISH. 

Carol Proxy Alice Appearance Agent Bob 
|«----- PUBLISH F1<| 
>F2 200 OK ------ > 


| 
<-- NOTIFY F3<| | 
>F4 200 OK --»| | 

| 


[Resta NOTIFY F5> 
<F6 200 OK ------ < 
| 
AA AI a INVITE F7«| 
| | | 
pee LOO, A >| 
«-- INVITE F9« 

«---- PUBLISH F10< 
| | | | 
| | |>F11 200 OK ----- >| 
| | | | 

>F12 180 ---»| | | 
>F13 180 Ringing ------------------------------- $ 
a A a et, vs, e > 


|<- NOTIFY F14< 


>F15 200 OK -> 
== NOTIFY F16> 


| | 
| |<F17 200 OK ----- <| 
>F18 200 OK ->| | | 
|>F19 200 OK ------------------------------------ >| 
| 

<--------------------------------------- ACK F20< 
«---- ACK F21<| | | | 
| 
< Both way RTP established > | 
| | | 
| 


| |<- NOTIFY F22<| 
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Figure 4. 
Fl to F4: 


to place an outgoing call (e.g., he goes off-hook). 
the outgoing INVITE request, 
reserving appearance number 1. 
(and all other UAs, 


including Bob) 


SIP Shared Appearances 


| 
|>F23 200 OK ->| 


F1 Bob ----» Appearance Agent 


PUBLISH sip:HelpDeskGexample.com SIP/2.0 
Via: SIP/2.0/UDP ua2.example.com;branch-z9hG4bK61314d6446383E79 


From: 


To: <sip:HelpDesk@example.com> 


CSeq: 


Call-ID: 
Contact: 


Event: 


Max-Forwards: 
Content-Type: 


7 PUBLISH 
44fwF144-F12893K38424 
<sip:bob@ua2.example.com> 
dialog; shared 

70 
application/dialog-info+xml 


Content-Length: 


<?xml version="1.0"?> 


March 2015 


II NOTIFY F24> 


|<F25 200 OK 


Outgoing Call with Appearance Seizure Example 


<sip:bob@example.com>; tag=44150CC6-A7B7919D 


<dialog-info xmlns-"urn:ietf:params:xml:ns:dialog-info" 
xmlns:sa-"urn:ietf:params:xml:ns:sa-dialog-info" 
version="6" 
state="full" 
entity="sip:HelpDesk@example.com"> 
«dialog id="id3d4f9c83" direction="initiator"> 
<sa:appearance>1</sa:appearance> 
<sa:exclusive>false</sa:exclusive> 
<state>trying</state> 


<local> 


«target uri="sip:bob@ua2.example.com"> 


</target> 
</local> 


</dialog> 
</dialog-info> 


Johnston, 


et al. 


Standards Track 


Bob uses the shared appearance of the Help Desk on his UA 
Before sending 
Bob publishes to the Appearance Agent 

The Appearance Agent notifies Alice 
of the event by sending NOTIFYs. 
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F2 Appearance Agent  ----» Bob 


SIP/2.0 200 OK 

Via: SIP/2.0/UDP ua2.example.com;branch-z9hG4bK61314d6446383E79 
From: «sip:bobGexample.com»;tag-44150CC6-A7B7919D 
To: <sip:HelpDesk@example.com> 

CSeq: 7 PUBLISH 

Call-ID: 44fwF144-F12893K38424 

Contact: <sip:bob@ua2.example.com> 

Event: dialog;shared 

SIP-Etag: 482943245 

Allow-Events: dialog 

Expires: 60 

Content-Length: 0 


F7 Bob ---» Proxy 


INVITE sip:carol@example.com SIP/2.0 

Via: SIP/2.0/UDP ua2.example.com;branch-z9hG4bK342122 
Max-Forwards: 70 

From: <sip:HelpDesk@example.com>; tag=15A3DE7C-9283203B 
To: <sip:carol@example.com> 

Call-ID: f3b3cbd0-a2c5775e-5df9f8d5 

CSeq: 31 INVITE 

Contact: <sip:bob@ua2.example.com> 

Content-Type: application/sdp 

Content-Length: 


(SDP Not Shown) 


F10 Bob ----» Appearance Agent 


PUBLISH sip:HelpDeskGexample.com SIP/2.0 

Via: SIP/2.0/UDP ua2.example.com;branch-z9hG4bK6d644638E7 
From: «sip:bobGexample.com»;tag-0CCf6-A7FdsB79D 
To: <sip:HelpDesk@example.com> 

CSeq: 437 PUBLISH 

Call-ID: fwF14d4-F1FFF2F2893K38424 

Contact: <sip:bob@ua2.example.com> 

Event: dialog;shared 

Max-Forwards: 70 

Content-Type: application/dialog-info+xml 
Content-Length: 


<?xml version="1.0"?> 
«dialog-info xmlns-"urn:ietf:params:xml:ns:dialog-info" 
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xmlns:sa-"urn:ietf:params:xml:ns:sa-dialog-info" 
version="6" 
state="full" 
entity="sip:HelpDesk@example.com"> 
<dialog id="id3d4f9c83" 
call-id-"f3b3cbd0-a2c5775e-5df9f8d5" 
local-tag="15A3DE7C-9283203B" 
direction="initiator"> 
<sa:appearance>1</sa:appearance> 
<sa:exclusive>false</sa:exclusive> 
<state>trying</state> 
<local> 
«target uri="sip:bob@ua2.example.com"> 
</target> 
</local> 
<remote> 
«identity uri-"sip:carolGexample.com"» 
«/identity» 
«/remote» 
«/dialog» 
</dialog-info> 


11.5. Outgoing Call without Using an Appearance Number 


In this scenario, Bob's UA sends out a dialog event PUBLISH with 
state (trying) indicating that he does not want to utilize an 
appearance number for this dialog. The PUBLISH does not have an 
appearance element but does have the 'shared' Event header field 
parameter. As a result, the Appearance Agent knows the UA does not 
wish to use an appearance number for this call. If the Appearance 
Agent does not wish to allow this, it would reject the PUBLISH with a 
400 (Bad Request) response and the UA would know to re-PUBLISH 
selecting/seizing an appearance number. 


Carol Proxy Alice Appearance Agent Bob 
| | | | 
| |«----- PUBLISH F1<| 
| 
| |>F2 200 OK ------ > 


«-- NOTIFY F3< 


| 
|>F4 200 OK -->| 

| | ------- NOTIFY F5> 
| 


«F6 200 OK ------ « 


«---------------2----2------------------ INVITE F7«| 


Johnston, et al. Standards Track [Page 42] 


RFC 7463 SIP Shared Appearances March 2015 


|>F8 100 Trying --------------------------------- >| 
«-- INVITE F9< 
«---- PUBLISH F10< 
| | | | 
| | |>F11 200 OK ----- >| 
| | | | 
>F12 180 ---»| | | | 
>F13 180 Ringing ------------------------------- > 
<===u=o==u===-=-=--- > 


|<- NOTIFY F14< 


|>F15 200 OK ->| 
------ NOTIFY F16> 


| |<F17 200 OK ----- <| 
>F18 200 OK ->| | | 
|>F19 200 OK ------------------------------------ > | 
| | | | 
A e uer ACK F20« 
«---- ACK F21< | | 
| | | 
< Both way RTP established > 
| 
SSeS A Sy SS SS > | 


«- NOTIFY F22< 


>F23 200 OK ->| 
| ------ NOTIFY F24> 


<F25 200 OK ----- « 


Figure 5. Outgoing Call without using an Appearance Number Example 


F1 Bob ----> Appearance Agent 


PUBLISH sip:appearanceagent.example.com SIP/2.0 

Via: SIP/2.0/UDP ua2.example.com;branch-z9hG4bK61314d6446383E79 
From: <sip:bob@example.com>; tag=4415df£82k39sf 

To: <sip:HelpDesk@example.com> 

CSeq: 7 PUBLISH 

Call-ID: 44fwF144-F12893K38424 

Contact: <sip:bob@ua2.example.com> 


Johnston, et al. Standards Track [Page 43] 


RFC 7463 SIP Shared Appearances March 2015 


Event: dialog;shared 

Max-Forwards: 70 

Content-Type: application/dialog-info+xml 
Content-Length: 


<?xml version="1.0"?> 
<dialog-info xmlns-"urn:ietf:params:xml:ns:dialog-info" 
xmlns:sa-"urn:ietf:params:xml:ns:sa-dialog-info" 
version="6" 
state="full" 
entity="sip:HelpDesk@example.com"> 
«dialog id="id3d4f9c83" direction="initiator"> 
<sa:exclusive>false</sa:exclusive> 
<state>trying</state> 
<local> 
«target uri="sip:bob@ua2.example.com"> 
</target> 
</local> 
</dialog> 
</dialog-info> 


Note that F7 would be the same as the previous example. 
11.6. Appearance Release 
Bob and Carol are in a dialog, created, for example as in 
Section 11.3. Carol sends a BYE to Bob to terminate the dialog and 


the Appearance Agent de-allocates the appearance number used, sending 
notifications out to the UAs in the shared group. 


Carol Proxy Alice Appearance Agent Bob 
| | | | | 
| | | | | 
< Both way RTP established > 
| | | 
|>F22 BYE ----»| | | 
| |>F23 BYE --------------------------------------- > 
| | | | 
| | La 200 OK F24< 


<--200 OK F25< 


«- NOTIFY F26«| 


>F27 200 OK ->| 
esses NOTIFY F28> 


| |<F29 200 OK ----- «| 
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Figure 6. Appearance Release Example 
F28 Appearance Agent ----> Bob 


NOTIFY sip:bob@ual.example.com SIP/2.0 

From: <sip:HelpDesk@example.com>; tag=497585728578386 

To: <sip:bob@example.com> 

Call-ID: a7d559db-d6d7dcad-311c9e3a 

CSeq: 7 NOTIFY 

Via: SIP/2.0/UDP appearanceagent.example.com 
;branch-z9hG4bK759878512309 

Max-Forwards: 70 

Content-Type: application/dialog-info+xml 

Event: dialog;shared 

Subscription-State: active;expires-1800 

Contact: <sip:appearanceagent.example.com> 

Content-Length: 


<?xml version="1.0"?> 
<dialog-info xmlns-"urn:ietf:params:xml:ns:dialog-info" 
xmlns:sa-"urn:ietf:params:xml:ns:sa-dialog-info" 
version="27" 
state="partial" 
entity="sip:HelpDesk@example.com"> 
«dialog id="f£a02538339df3ce597£9e3e3699e28fc" 
call-id-"f3b3cbd0-a2c5775e-5df9f8d5" 
local-tag="15A3DE7C-9283203B" 
remote-tag="65a98f7c-1dd2-11b2-88c6-b0316298f£7c" 
direction="initiator"> 
<sa:appearance>1</sa:appearance> 
<sa:exclusive>false</sa:exclusive> 
<state>terminated</state> 


<local> 
«target uri="sip:bob@ua2.example.com"> 
</target> 
</local> 
</dialog> 


</dialog-info> 


11.7. Appearance Pickup 


In this scenario, Bob has an established dialog with Carol created 
using the call flows of Figures 1 or 2. Bob then places Carol on 
hold. Alice receives a notification of this and renders this on 
Alice's UI. Alice subsequently picks up the held call and has a 
established session with Carol. Finally, Carol hangs up. Alice must 
PUBLISH F32 to indicate that the INVITE F38 will be an attempt to 
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pickup the dialog between Carol and Bob and, hence, may use the same 
appearance number. This example also shows Secure SIP (sips) being 


used. 

Carol Proxy Alice Appearance Agent Bob 

| | | | | 

|< Both way RTP established >| 

| | | | | 
<------------------------------ (hold) INVITE F22< 

«- INVITE F23< | 

| | | | | 

|>F24 200 OK ->| | | 

| |>F25 200 OK ------------------------------------ > 

| | | | 

| | <--------------------------------------- ACK F26< 

«---- ACK F27< | 


|<- NOTIFY F28«| 


>F29 200 OK ->| 
>F30 NOTIFY ----- > 


|«----- 200 OK F31« 


Alice decides to pick up the call 


|<- 200 OK F33«| 


|<- NOTIFY F34<| 


>F35 200 OK -> 


| 

| 

| 

| | 

| | 

| | 

| | | 
>F32 PUBLISH-> | 

| | 

| | 

| | 

| 

| 

| 


>F36 NOTIFY ----- > 

| | | 

| |<----- 200 OK F37<| 

|<-- INVITE F38«| | | 

|<- INVITE F39«|(w/ Replaces) | | 

( w/ Replaces) 
>F40 200 OK -> 

| |>F41 200 OK --»| | | 

| | | | 

| Rese Hee >| | 

| | | | | 

| | | >F42 NOTIFY ----- > 

| | | |<----- 200 OK F43<| 
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|<- NOTIFY F44<| 


>F45 200 OK -> 


«----- ACK F46<| 
«---- ACK F47<| 


<= Both way RIP established => 


>F48 BYE ----> 
| | | 
| <------------------------------------ OK 200 F50< 
«- 200 OK F51«| | | 
| | | 
<------- - ee eee > 


|<- NOTIFY F52<| 


>F53 200 OK ->| 


| 
| 
| 
| 
|>F49 BYE --------------------------------------- > | 
| 
| 
| 
| 
| 
| 
| 


>F54 NOTIFY ----- > 


| |«----- 200 OK F55«| 


Figure 7. Appearance Pickup Example 


F28 Appearance ----» Alice 


NOTIFY sips:aliceQual.example.com SIP/2.0 

From: <sips:HelpDeskfexample.com>;tag=151702541050937 

To: <sips:alice@example.com>; tag=18433323-C3D237CE 

Call-ID: 1le361d2f-a9f51109-bafe31d4 

CSeq: 12 NOTIFY 

Via: SIP/2.0/TLS appearanceagent.example.com 
;branch-z9hG4bK1403 

Max-Forwards: 70 

Content-Type: application/dialog-info+xml 

Event: dialog;shared 

Subscription-State: active;expires-1800 

Contact: <sips:appearanceagent.example.com> 

Content-Length: 


<?xml version="1.0"?> 

<dialog-info xmlns-"urn:ietf:params:xml:ns:dialog-info" 
xmlns:sa-"urn:ietf:params:xml:ns:sa-dialog-info" 
version="10" 
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state-"partial" 
entity="sips:HelpDesk@example.com"> 
«dialog id-"id3d4f9c83" 
call-id-"f3b3cbd0-a2c5775e-5df9f8d5" 
local-tag="15A3DE7C-9283203B" 
remote-tag="65a98f7c-1dd2-11b2-88c6-b0316298f£7c" 
direction="initiator"> 
<sa:appearance>1</sa:appearance> 
<sa:exclusive>false</sa:exclusive> 
<state>active</state> 
<local> 
<target uri="sips:bob@ua2.example.com"> 
<param pname="+sip.rendering" pval="no"/> 
</target> 
</local> 
<remote> 
<identity>sips:carol@example.com</identity> 
<target uri="sips:carol@ua3.example.com" /> 
</remote> 
</dialog> 
</dialog-info> 


F32 Alice ----» Appearance Agent 


PUBLISH sips:HelpDesk@example.com SIP/2.0 

Via: SIP/2.0/TLS ua2.example.com; branch=z9hG4bKa5d6cf61F5FBCO5A 
From: <sips:HelpDesk@example.com>; tag=44150CC6-A7B7919D 
To: <sips:alice@example.com>;tag=428765950880801 

CSeq: 11 PUBLISH 

Call-ID: 87837Fkw87asfds 

Contact: <sips:alice@ua2.example.com> 

Event: dialog; shared 

Max-Forwards: 70 

Content-Type: application/dialog-info+xml 
Content-Length: 


<?xml version="1.0"?> 
«dialog-info xmlns-"urn:ietf:params:xml:ns:dialog-info" 
xmlns:sa-"urn:ietf:params:xml:ns:sa-dialog-info" 
version="10" 
state="full" 
entity="sips:HelpDesk@example.com"> 
«dialog id-"id3d4f9c83" 
call-id-"3d57cd17-47deb849-dca8b6c6" 
local-tag="8C4183CB-BCEAB710" > 
<sa:appearance>1</sa:appearance> 
<sa:exclusive>false</sa:exclusive> 
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<sa:replaced-dialog 
call-id-"f3b3cbd0-a2c5775e-5df9f8d5" 
from-tag="15A3DE7C-9283203B" 
to-tag-"65a98f7c-1dd2-1102-88c6-5003162323164-65a98f7c" /» 
<state>trying</state> 
<local> 
«target uri-"sips:aliceQual.example.com"» 
<param pname="+sip.rendering" pval="yes"/> 
</target> 
</local> 
<remote> 
«target uri-"sips:carolQua3.example.com" /> 
</remote> 
</dialog> 
</dialog-info> 


F38 Alice ----> Proxy 


INVITE sips:carolGexample.com SIP/2.0 

Via: SIP/2.0/TLS ual.example.com;branch-z9hG4bK4ea695b5B376A60C 
From: <sips:HelpDesk@example.com>;tag=8C4183CB-BCEAB710 

To: <sips:carol@example.com:5075> 

CSeq: 1 INVITE 

Call-ID: 3d57cd17-47deb849-dca8b6c6 

Contact: <sips:alice@ual.example.com> 

«all-one-line» 

Replaces: f3b3cbd0-a2c5775e-5df9f8d5;to-tag-65a98f7c 
-1dd2-11b2-88c6-b03162323164+65a98f7c;from-tag=15A3DE7C-9283203B 
</all-one-line> 

Max-Forwards: 70 

Content-Type: application/sdp 

Content-Length: 223 


v=0 

o=- 1102980497 1102980497 IN IP4 ual.example.com 
s=IP SIP UA 

C-IN IP4 ual.example.com 

t-0 0 

a-sendrecv 

m-audio 2238 RTP/AVP 0 8 101 

a-rtpmap:0 PCMU/8000 

a-rtpmap:8 PCMA/8000 

a-rtpmap:101 telephone-event/8000 
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11.8. Call between UAs within the Group 


In this scenario, 
appearance group. 


dialog. 
dialog. 


Carol 


Johnston, 


Bob calls Alice who is also in the shared 
Only one appearance number is used for this 


This example also shows the use of the 'exclusive' tag to 
indicate that other UAs in the group Can not join or take this 


et al. 


Proxy 


|<-- NOTIFY F9«| 


Alice Appearance Agent Bob 
| | 
| <-------------------- INVITE (to Alice’s UA) F1<| 
| | | | 
[eee ee ets eet eee >| | 
| | | | 
| | | | 
| «-- NOTIFY F2< | 
| |>F3 200 OK --»| | 
| | |>F4 NOTIFY ------ >| 
| | | | 
| | |<------ 200 OK F5<| 
>F6 INVITE ---> 

(appearance=1) 
| | | 
poe 180 F7«| | | 
| | | 
|>F8 180 --------------------------------------- >| 
| 
du a mi See ee > 
| 
| 
| 
| 


«-- 200 OK F13<| 


|>F10 200 OK ->| 


>F14 200 OK ----- 
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|<- NOTIFY F17«| 


>F18 200 OK -> 


>F19 NOTIFY ----- > 


| | | | 
| | | |«----- 200 OK F24«| 
| | | | 


Figure 8. Call between UAs within the Group Example 


F19 Appearance Agent ----> Bob 


NOTIFY sip:bob@ual.example.com SIP/2.0 

From: <sip:HelpDesk@example.com>; tag=497585728578386 

To: <sip:bob@example.com>; tag=633618CF-B9C2EDA4 

Call-ID: a7d559db-d6d7dcad-311c9e3a 

CSeq: 7 NOTIFY 

Via: SIP/2.0/UDP appearanceagent.example.com 
;branch-z9hG4bK1711759878512309 

Max-Forwards: 70 

Content-Type: application/dialog-info+xml 

Event: dialog;shared 

Subscription-State: active;expires-1500 

Contact: <sip:appearanceagent.example.com> 

Content-Length: 


<?xml version="1.0"?> 
<dialog-info xmlns-"urn:ietf:params:xml:ns:dialog-info" 
xmlns:sa-"urn:ietf:params:xml:ns:sa-dialog-info" 
version="10" 
state="partial" 
entity="sip:HelpDesk@example.com"> 
«dialog id="3xdsd4f£9c83" 
call-id-"b3cbd0-ad2c5775e-5df9f8d5" 
local-tag="34322kdfr234f" 
remote-tag="3153DE7C-928203B" 
direction="initiator"> 
<sa:exclusive>true</sa:exclusive> 
<sa:appearance>1</sa:appearance> 
<state>confirmed</state> 
<local> 
«target uri="sip:bob@ua2.example.com"> 
</target> 
</local> 
<remote> 
<identity>sip:HelpDesk@example.com</identity> 
<target uri="sip:alice@ual.example.com" /> 
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11. 


«/remote» 
«/dialog» 


«dialog id="4839589" 
call-id-"b3cbd0-ad2c5775e-5df9f8d5" 
local-tag="3153DE7C-928203B" 

remote-tag="34322kdfr234f" 
direction="responder"> 
<sa:exclusive>true</sa:exclusive> 
<sa:appearance>1</sa:appearance> 
<state>confirmed</state> 
<local> 
«target uri="sip:alice@ual.example.com" /» 

«/local» 

«remote» 
<identity>sip:HelpDesk@example.com</identity> 
<target uri="sip:bob@ua2.example.com" /> 

</remote> 

</dialog> 


</dialog-info> 
9. Consultation Hold with Appearances 


In this scenario, Bob has a call with Carol. Bob makes a 
consultation call to Alice by putting Carol on hold and calling 
Alice. Bob's UA chooses not to have an appearance number for the 
call to Alice since it is treating it as part of the call to Carol. 
He indicates this in the PUBLISH F32, which contains the ’shared’ 
Event header field parameter but no «appearance» element. The 
PUBLISH is sent before the INVITE to Alice to ensure no appearance 
number is assigned by the Appearance Agent. Finally, Bob hangs up 
with Alice and resumes the call with Carol. Dialog notifications of 
the consultation call are not shown, as they are not used. 


Note that if Carol hangs up while Bob is consulting with Alice, Bob 
can decide if he wants to reuse the appearance number used with Carol 
for the call with Alice. If not, Bob publishes the termination of 
the dialog with Carol and the Appearance Agent will re-allocate the 
appearance. If he wants to keep the appearance, Bob will publish the 
termination of the dialog with Carol and also publish the appearance 
with the dialog with Alice. This will result in Bob keeping the 
appearance number until he reports the dialog with Alice terminated. 


Note that the call flow would be similar if Bob called a music on 
hold server instead of Alice to implement a music on hold service as 
described in [RFC7088]. 
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Carol Proxy Alice Appearance Agent Bob 
< Both way RTP established > 
| <------------------------------ (hold) INVITE F22«| 


|<- INVITE F23«| | | 


|>F24 200 OK ->| | | 


| >F25 200 OK ----------------------------------—— > 
| 

| LT ACK F26«| 

|«---- ACK F27<| | | 

| M E c E > | 

| | | | | 

| |<- NOTIFY F28<| | 

| >F29 200 OK -> | 

| | | |>F30 NOTIFY ----- > | 

| | | | 

| | | |<----- 200 OK F31<| 

| | | | 

| | Bob makes a consultation call to Alice 

| | | |<---- PUBLISH F32«| 

| | | | 

| | |>F33 200 OK ----- >| 

| | | 

| <------------------------------------ INVITE F34< 
| | 

| |>F35 INVITE --»| | 

| | | | 

| |<-- 200 OK F36<| | | 

| | | | 

| REST 200 OK ----------------------------------—- > 
| | 

| «--------------------------------------- ACK F38«| 

| | | | 

| >F39 ACK ----- >| | 

| | | 

| <======= RTP established =======> 

| 

| 

| 

| 


[«-- 200 OK F42<| | 


Johnston, et al. Standards Track [Page 53] 


RFC 7463 


SIP Shared Appearances 


March 2015 


Figure 9. Consultation Hold with Appearances Ex 


F32 Bob ----» Appearance Agent 


PUBLISH sip:HelpDeskGexample.com SIP/2.0 
Via: SIP/2.0/UDP ua2.example.com;branch-z9hG4bKa5d6cf61F5FBC05A 


From: 


| 
| |>F43 200 OK ------------------- 

| | 
| Keane oran (unhold) INVITE F44< 
|<- INVITE F45<| | | | 
| | | | | 
|>F46 200 OK ->| | | | 
| |>F47 200 OK ------------------------------------ >| 

| | 
| <--------------------------------------- ACK F48< 
|<---- ACK F49<| | | | 
| MEE ME i | 
| | |<- NOTIFY F50<| | 
| | | | | 

>F51 200 OK -> 
>F52 NOTIFY ----- > 

| | | | | 
| | | |<----- 200 OK F53«| 
| | | | | 
|< Both way RTP established >| 
| | 


ample 


«sip:bobüexample.com»;tag-44150CC6-A7B7919D 


To: <sip:HelpDesk@example.com>; tag=428765950880801 


CSeq: 


11 PUBLISH 


Call-ID: 44fwF144-F12893K38424 
Contact: <sip:bob@ua2.example.com> 


Event: 


dialog; shared 


Max-Forwards: 70 
Content-Type: application/dialog-info+xml 
Content-Length: 


<?xml version="1.0"?> 
<dialog-info xmlns-"urn:ietf:params:xml:ns:dialog-info" 


xmlns:sa-"urn:ietf:params:xml:ns:s 
version="10" 
state="full" 
entity="sip:HelpDesk@example.com"> 


«dialog id-"id3d4f9c83" 


Johnston, 


call-id-"b3cbd0-ad2c5775e-5df9f8d5" 
local-tag="3153DE7C-928203B" 


et al. Standards Track 


a-dialog-info" 
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direction-"initiator"» 
<sa:exclusive>true</sa:exclusive> 
<state>trying</state> 

<local> 
«target uri="sip:bob@ua2.example.com"> 
«/target» 

«/local» 

«remote» 
<identity>sip:HelpDesk@example.com</identity> 
<target uri="sip:alice@ual.example.com" /> 

</remote> 

</dialog> 


</dialog-info> 


11.10. Joining or Bridging an Appearance 


In this call flow, 
"bridged". 
bridging. 


conferencing resources as described in [RFC4579]. 


Carol 


Forking Proxy Appearance Agent Alice B 


Both way RTP established=========== > 


|< 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 


Johnston, 


et al. 


|< PUBLISH F22| 


O 
| 
| 
| 
| 
| 
| 
| 
| 
| 


| 
| 
| 
| >F23 200 OK > 
| 
| 
| 
| 


«---- INVITE (w/ Join) F24«| 

>F25 INVITE TET REE. ate ir LES > 
<---- OK 200 HER ake F26< 
<---- - j| 


| 
| | 
|>F27 NOTIFY >| 


| 
| 
| 
| 
| « 200 OK F28« 
| 
| 
| 
| 


| 
| 
| 
|>F29 NOTIFY ---------- »| 
| 
| 
| 


| | 
|<F30 200 OK ---------- < 
| | 
>F31 200 OK Contact:B----- > 
| <----------------- ACK F32<| 


Standards Track 


March 2015 


a call answered by Bob is joined by Alice or 
The Join header field is used by Alice to request this 


If Bob did not support media mixing, Bob could obtain 
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[SACK _F33---------------------------- > 

| | 
«----- INVITE Contact:Bob;isfocus F34« 
«-INVITE F35| | | | 
| | 
>F26 200 --»| | | | 
|>F37 200 OK ------------------------ > | 

| | 
Em ACK F38< 

«--- ACK F39| | | 
| | | <==RTP ==> 

| | 

<----- >| | 


>F40 NOTIFY > 


| 
| 
| |< 200 OK F41«| 
| 
| 


|>F42 NOTIFY ---------- > 


<F43 200 OK ---------- < 


Figure 10. Joining or Bridging an Appearance Example 


| 
| 
| 
| 
| 
|< Both way RTP established=========== > 
| 
| 
| 
| 
| 
| 


F22 Alice ----» Appearance Agent 


PUBLISH sip:HelpDeskGexample.com SIP/2.0 

Via: SIP/2.0/UDP ua2.example.com;branch-z9hG4bKa5d6cf61F5FBC05A 
From: <sip:alice@example.com>; tag=44150CC6-A7B7919D 
To: <sip:HelpDesk@example.com>; tag=428765950880801 
CSeq: 11 PUBLISH 

Call-ID: 87837Fkw87asfds 

Contact: <sip:alice@ua2.example.com> 

Event: dialog; shared 

Max-Forwards: 70 

Content-Type: application/dialog-info+xml 
Content-Length: 


<?xml version="1.0"?> 
<dialog-info xmlns-"urn:ietf:params:xml:ns:dialog-info" 
xmlns:sa-"urn:ietf:params:xml:ns:sa-dialog-info" 
version="10" 
state="full" 
entity="sip:HelpDesk@example.com:5060"> 
«dialog id-"id3d4f9c83" 
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call-id-"dc95da63-60dblabd-d5a74b48" 
local-tag="605AD957-1F6305C2" > 
<sa:appearance>1</sa:appearance> 
<sa:exclusive>false</sa:exclusive> 
«sa: joined-dialog 
call-id-"14-1541707345" 
from-tag="44BAD75D-E3128D42" 
to-tag="d3b06488-1dd1-11b2-88c5-b03162323164+d3e48f4c" /> 
<state>trying</state> 
<local> 
«target uri-"sip:aliceQual.example.com"» 
«/target» 
«/local» 
«remote» 
«target uri="sip:bob@example.com" /» 
«/remote» 
«/dialog» 
</dialog-info> 


F24 Alice ----> Proxy 


INVITE sip:bob@ua.example.com SIP/2.0 

Via: SIP/2.0/UDP ual.example.com;branch-z9hG4bKcc9d727c2C29BE31 
From: <sip:HelpDesk@example.com>; tag=605AD957-1F6305C2 
To: <sip:bob@ua.example.com> 

CSeq: 2 INVITE 

Call-ID: dc95da63-60dblabd-d5a74b48 

Contact: <sip:alice@ual.example.com> 

«all-one-line» 

Join: 14-1541707345;to-tag=d3b06488-1dd1-11b2-88c5 
-b03162323164+d3e48f4c;from-tag=44BAD75D-E3128D42 
</all-one-line> 

Max-Forwards: 70 

Content-Type: application/sdp 

Content-Length: 223 


v=0 

o-- 1103061265 1103061265 IN IP4 ual.example.com 
s=IP SIP UA 

C-IN IP4 ual.example.com 

t=0 0 

a=sendrecv 

m-audio 2236 RIP/AVP 0 8 101 

a=rtpmap:0 PCMU/8000 

a=rtpmap:8 PCMA/8000 

a=rtpmap:101 telephone-event/8000 
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11.11. Loss of Appearance during Allocation 


Bob reserves an appearance with a PUBLISH, sends an INVITE to Carol, 
then becomes unreachable. When he fails to refresh his publication 
to the appearance agent, the Appearance Agent declares the dialog 
terminated and frees up the appearance using NOTIFYs F14 and F16. 
After retransmitting the NOTIFY to Bob (in not shown messages F17, 


F18, etc.), 


Carol 


Figure 11. 


Johnston, 


>F12 180 


«-- INVITE F9« 


et al. 


---» 


the subscription is terminated. 


Proxy Alice Appearance Agent Bob 
| | | | 
| |<----- PUBLISH F1<| 
| 
| |>F2 200 OK ------ > 
| 


| 

| | 
| | 
| | 
| «-- NOTIFY F3« | 
| | 
| | 
| | 
| | 


| 
| |------- NOTIFY F5> 
| 
| |<F6 200 OK ------ < 
| 
«--------------2----------------------- INVITE F7« 
| | | 
>F8 100 Trying --------------------------------- > | 
| | | 
| |<---- PUBLISH F10<| 
| »F11 200 OK ----- > 
| | | 
| | | 
>F13 180 Ringing ------------------------------- >| 
| 


| Bob goes offline 


| Appearance selection times out 
| 
|<- NOTIFY F14<| 

| 


>F15 200 OK -> 


------ NOTIFY F16> 


NOTIFY is retransmitted | 


Loss of Appearance during Allocation Example 
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11.12. Appearance Seizure Contention Race Condition 


Bob and Alice both try to reserve appearance 2 by publishing at the 
same time. The Appearance Agent allocates the appearance to Bob by 
sending a 200 OK and denies it to Alice by sending a 400 (Bad 
Request) response. After the NOTIFY F5, Alice learns that Bob is 
using appearance 2. Alice then attempts to reserve appearance 3 by 
publishing, which is then accepted. 
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Proxy 


<- INVITE F11< 


<- INVITE F22«| 


| 
| 
| 
| 
| 
| 
| 
| 
| 
|>F10 100 Trying 
| 
| 
| 
| 
| 
| 
| 
| 
| 


| 

<-- INVITE F20<| 
| 

|>F21 100 | 
| 


SIP Shared Appearances 


Alice 


|>F2 PUBLISH ->| 


<---- F4 400 < 


|<-- NOTIFY F5«| 


|>F6 200 OK -->| 


|<- NOTIFY F16<| 


|>F17 200 OK ->| 


Appearance Agent 


(appearance-2) 


March 2015 


Bob 


PUBLISH F1<| 
(appearance-2) 


>F3 200 OK ------ > 


| | ------- NOTIFY F7> 

| 

| «F8 200 OK ------ « 
<------------------------------------- INVITE F9«| 

| | | 

E SSeS SoG Se eee See esas > | 

| | | 

«---- PUBLISH F12<| 

| | (appearance-2) 

| |>F13 200 OK ----- > | 

|>F14 PUBLISH-»| | 

| (appearance=3) 

| 

«--- F15 200 < 


«F19 200 OK ----- < 


Figure 12. Appearance Seizure Contention Race Condition Example 


ELSES; 


In this scenario, 


knowing Bob's dialog state information, 


Appearance Agent Subscription to UAs 


except 


the Appearance Agent does not have any way of 


through Bob. This 


could be because the Appearance Agent is not part of a B2BUA, or 


Johnston, et al. 
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perhaps Bob is remotely registering. When Bob registers, the 
Appearance Agent receives a registration event package notification 
from the registrar. The Appearance Agent then SUBSCRIBEs to Bob's 
dialog event state using Event:dialog in the SUBSCRIBE. Whenever 
Bob's dialog state changes, Bob's UA sends a NOTIFY to the Appearance 
Agent which then notifies the other UAs in the group. 


Carol Proxy Alice Appearance Agent Bob 
A -------------------- REGISTER F1< 
|>F2 200 OK € — ----------------- A 
|>F3 NOTIFY zn ------------- e 
A 200 OK pud 


---- SUBSCRIBE F5» 


| 
|<F6 200 OK ------ «| 
| 
| 


A 


FPS NOTIFY F7< 


>F8 200 OK ------ > 


| 
| 
| 
| 
| 
| |<--- SUBSCRIBE F9«| 
| 
| 
| 
| 
| 


|>F10 200 OK ----- > | 


------ NOTIFY F11> 


| 
|<F12 200 OK ----- «| 
| 
LO INVITE F13«| 
| | 
>F14 100 Trying -------------------------------- > 
<- INVITE F15< | | | 
| |«----- NOTIFY F16<| 
| | 
| |>F17 200 OK ----- > 


<- NOTIFY F18< 


|------ NOTIFY F20> 


| 
>F19 200 OK ->| | 
| 
| 
| 


|<F21 200 OK ----- < 


>F22 180 ---> 


>F23 180 Ringing ------------------------------- > 
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=> 


>F30 200 OK 
>F31 200 OK 


«---- ACK F35«| 


| 
| 
| 
| 
| 
| 
|< 
| 
| 
| 
| 
| 
| 


SIP Shared Appearances 


Both way RTP established 


NOTIFY F24<| 


^ 
| 
l 
| 


>F25 200 OK 


NOTIFY F26< 


| 
>F27 200 OK ->| 


| 
NOTIFY F28>| 
| 


<F29 200 OK ----- « 
E >| 
| | | 
| |«----- NOTIFY F32«| 
| | | 
| |>F33 200 OK ----- >| 

| | 
------------------------- ACK F34« 

| | 
> 


<r 


>F37 200 OK ->| 


NOTIFY F38> 


| 

| 

| 

NOTIFY F36< | 
| 

| 

| 

|<F39 200 OK | 

| 


Figure 13. Appearance Agent Subscription to UAs Example 


11.14. 


In this scenario, 


on hold. 
Alice’s UI. 
before the pickup can complete. 
with the PUBLISH F48. 
would be almost identical. 


Carol Proxy 


|< 


|<- INVITE F23<| 


Johnston, et al. 


Alice 


Both way RTP established 


Standards Track 


Appearance Pickup Race Condition Failure 


Bob has an established dialog with Carol created 
using the call flows of Figure 1 or Figure 2. 
Alice receives a notification of this and renders this on 
Alice attempts to pick up the call but Carol hangs up 


Alice cancels the pickup attempt 


Note that the call flow for a failed Join 


Appearance Agent 


v 


(hold) INVITE F22< 
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| | 
>F24 200 OK ->| | | 


| 

| >F25 200 OK ----------------------------------—— > 
| 

| «--------------------------------------- ACK F26«| 

|<---- ACK F27<| | | | 

| | | | 

| [Ss >| | 

| | «- NOTIFY F28< | 

| | | | 

| |>F29 200 OK ->| 

| | |>F30 NOTIFY ----- > 

| | | | 

| | |<----- 200 OK F31<| 

| | 

| Alice decides to pick up the call 

| | | 

| | |>F32 PUBLISH-»| | 

| | | 

| | |<- 200 OK F33<| | 

| | <- NOTIFY F34< 

| | | 

| | |>F35 200 OK ->| | 

| | | |>F36 NOTIFY ----- >| 

| | | 
<----- 200 OK F37< 

>F38 BYE ----> 

| |>F39 BYE --------------------------------------- > 

| | | | 

| | La OK 200 F40< 

| 


<- 200 OK F41<| | 
<-- INVITE F42< 
(w/ Replaces) 


<- INVITE F43< 
( w/ Replaces) 


>F45 481 ----- > 


«----- ACK F47< 
|>F48 PUBLISH-> 


|<- 200 OK F49<| 


«- NOTIFY F50« 


[»F51 200 OK ->| | 
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| | | |>F52 NOTIFY ----- > 


| | | |<----- 200 OK F53< 
Figure 14. Appearance Pickup Race Condition Failure Example 
F48 Alice ----> Appearance Agent 


PUBLISH sip:HelpDeskGexample.com SIP/2.0 

Via: SIP/2.0/UDP ua2.example.com;branch-z9hG4bKa5d6cf61F5FBC05A 
From: <sip:alice@example.com>; tag=44150CC6-A7B7919D 
To: <sip:HelpDesk@example.com>; tag=428765950880801 
CSeq: 11 PUBLISH 

Call-ID: 87837Fkw87asfds 

Contact: <sip:alice@ua2.example.com> 

Event: dialog; shared 

Max-Forwards: 70 

Content-Type: application/dialog-info+xml 
Content-Length: 


<?xml version="1.0"?> 
<dialog-info xmlns-"urn:ietf:params:xml:ns:dialog-info" 
xmlns:sa-"urn:ietf:params:xml:ns:sa-dialog-info" 
version="10" 
state="full" 
entity="sip:HelpDesk@example.com"> 
«dialog id-"id3d4f9c83" 
call-id-"dc95da63-60dblabd-d5a74b48" 
local-tag="605AD957-1F6305C2" > 
<sa:appearance>1</sa:appearance> 
<sa:exclusive>false</sa:exclusive> 
<sa:replaced-dialog 
call-id-"14-1541707345" 
from-tag="44BAD75D-E3128D42" 
to-tag="d3b06488-1dd1-11b2-88c5-b03162323164+d3e48f4c" /> 
<state>terminated</state> 
<local> 
«target uri-"sip:aliceQual.example.com"» 
«/target» 
«/local» 
«remote» 
«target uri="sip:carol@ua3.example.com" /» 
«/remote» 
«/dialog» 
</dialog-info> 
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11.15. Appearance Seizure Incoming/Outgoing Contention Race Condition 


Alice tries to seize appearance 2 at the same time appearance 2 is 
allocated to an incoming call. The Appearance Agent resolves the 
conflict by sending a 400 (Bad Request) to Alice. After the NOTIFY 
F6, Alice learns that the incoming call is using appearance 2. Alice 
republishes for appearance 3, which is accepted. Note that this 
example shows the INVITE being received before the NOTIFY from the 
Appearance Agent. 
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Carol Proxy Alice Appearance Agent B 


>-- INVITE F1» 


|>F2 PUBLISH -»| 
| (appearance-2) 


>F3 INVITE (appearance-2) ---------------------- > 


>F4 INVITE | 
(appearance=2)> | 
|<---- F5 400 < 


|<-- NOTIFY F6<| 


>F7 200 OK --> 
| == NOTIFY F8> 


| 
| |<F9 200 OK ------ < 
| 


| 
| 
| 
| 
| 
| 
| 
>F10 PUBLISH-»| 
(appearance=3) 
| 
| 
| 
| 
| 
| 
| 


|< F11 200 OK <| 


|<- NOTIFY F12<| 


>F13 200 OK -> 
ave 


«F15 200 OK ----- « 


— 


| 
| 
«-- INVITE F16<| 


>F17 100 ----- > 
|<- INVITE F18<| | 


Figure 15. Appearance Seizure Incoming/Outgoing Contention 
Race Condition Example 


12. Security Considerations 


Since multiple line appearance features are implemented using 
semantics provided by SIP [RFC3261], the SIP Event Package for Dialog 
State [RFC4235], and the SIP Event Framework [RFC6665] and [RFC3903], 
security considerations in these documents apply to this document as 
well. 
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13; 


13; 


Jo 


To provide confidentiality, NOTIFY or PUBLISH message bodies that 
provide the dialog state information and the dialog identifiers MAY 
be encrypted end-to-end using the standard mechanisms such as S/MIME 
described in [RFC3261]. Alternatively, sending the NOTIFY and 
PUBLISH requests over TLS also provides confidentiality, although on 
a hop-by-hop basis. All SUBSCRIBEs and PUBLISHes between the UAs and 
the Appearance Agent MUST be authenticated. Without proper 
authentication and confidentiality, a third party could learn 
information about dialogs associated with a AOR and could try to use 
this information to hijack or manipulate those dialogs using SIP call 
control primitives. 


This feature relies on standard SIP call control primitives such as 
Replaces and Join. Proper access controls on their use MUST be used 
so that only members of the shared appearance group can use these 
mechanisms. All INVITEs with Replaces or Join header fields MUST 
only be accepted if the peer requesting dialog replacement or joining 
has been properly authenticated using a standard SIP mechanism (such 
as Digest or S/MIME), and authorized to request a replacement. 
Otherwise, a third party could disrupt or hijack existing dialogs in 
the shared appearance group. 


For an emergency call, a UA MUST NOT wait for a confirmed seizure of 
an appearance before sending an INVITE. Waiting for confirmation 
could inadvertently delay or block the emergency call, which by its 
nature needs to be placed as expeditiously as possible. Instead, a 
emergency call MUST proceed regardless of the status of the PUBLISH 
transaction. 


IANA Considerations 

This section registers the SIP Event header field parameter 'shared', 
the SIP Alert-Info header field parameter 'appearance', and the XML 
namespace extensions to the SIP Dialog Package. 

1. SIP Event Header Field Parameter: shared 

This document defines the 'shared' header field parameter in the 
Event header field in the "Header Field Parameters and Parameter 
Values" registry defined by [RFC3968]. 

Predefined 

Header Field Parameter Name Values Reference 
Event shared No REC 7463 
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13 


1343 


13. 


.2. SIP Alert-Info Header Field Parameter: appearance 


This document defines the 'appearance” parameter in the Alert-Info 
header in the "Header Field Parameters and Parameter Values" registry 
defined by [RFC3968]. 


Predefined 
Header Field Parameter Name Values Reference 
Alert-Info appearance No RFC 7463 
3. URN Sub-Namespace Registration: sa-dialog-info 


This section registers a new XML namespace per the procedures in 
[RFC3688]. 


URI: urn:ietf:params:xml:ns:sa-dialog-info. 


Registrant Contact: IETF BLISS working group, <bliss@ietf.org>, 
Alan Johnston <alan.b.johnston@gmail.com> 


XML: 


BEGIN 
<?xml version="1.0"?> 
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN" 
"http://www.w3.org/TR/xhtml-basic/xhtml-basicl0.dtd"> 
<html xmlns-"http://www.w3.org/1999/xhtml"» 
<head> 
<meta http-equiv="content-type" 
content-"text/html;charset-iso-8859-1"/» 
<title>Shared Appearance Dialog Information Namespace</title> 
</head> 
<body> 
«hl»Namespace for Shared Appearance Dialog Information</h1> 
<h2>urn:ietf:params:xml:ns:sa-dialog-info</h2> 
<p>See <a href-"http://www.rfc-editor.org/rfc/rfc7463.txt"» 
RFC 7463</a>.</p> 
</body> 
</html> 
END 


4. XML Schema Registration 


This section registers an XML schema per the procedures in [RFC3688]. 
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URI: urn:ietf:params:xml:schesa:sa-dialog-info. 


Registrant Contact: IETF BLISS working group, <bliss@ietf.org>, 
Alan Johnston <alan.b.johnston@gmail.com> 


The XML for this schema can be found in Section 6. 
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